folta@tove.umd.edu (Wayne Folta) (12/31/88)
There are several threads swirling around the Mac interface issue, so I may be confused, but I think we might need to clarify what we mean by "command line interface", as somehow opposed to the Mac interface. There appear to be two meanings here: 1. Doing things, especially in an editor/word processor, without taking your fingers off of the keyboard. 2. Having a UNIX-like shell. I hope that issue 1 has been laid to rest with my (and Microsoft's) comments: you can do any word processing from the Macintosh keyboard that you can do from the menus. And it can sometimes be more efficient, as Word can embolden characters with one keystroke, while you need several to get the nroff codes. But issue 2 is involved. Obviously, a shell command-line interface is useful for certain, concrete reasons. What are they? Maybe we could get some concrete comments here, beyond "It is faster" (e.g. what is meant by "it"?). At work/school, I have used UNIX on platforms from Suns to Crays. At home, I have owned an IBM and an Amiga, but I now use Macintosh exclusively. My observations are: 1. The shell allows you to "move" faster, e.g. with "cd /usr/folta/src/proj1". You don't have to move from folder to folder, as on the Mac. 2. The shell allows you to have shell scripts, which automate repetitive tasks. 3. The shell allows you to use pipes. E.g. "cat x y z | sort | uniq | pr | lpr". Advantage 1 can be somewhat alleviated with such Mac programs as Power Station (a Finder replacement, which gives you non-hierarchial access to programs and data), and HFS Navigator (a replacement for the standard "Open" dialog, which allows you to jump directly to oft-used directories without navigating the Mac file hierarchy). Advantage 2 can be alleviated (depending on your repetitive task) with such macro facilities as MacroMaker and AutoMac. Advantage 3 cannot really be answered, except by concentrating power in individual applications, so that tasks commonly performed with multiple programs can be done in one program. This solution is not as elegant as pipes, but Mac word processors do everything that you would have to use about 3 nroff pre-processors to do. [Speaking of speed advantages, nroff is no speed demon. Someone complained about the Mac's slow printing on 500-page documents, but how long does it take to nroff a 500-page document? I've had fairly simple 150-page nroff files take 20 minutes just to format. Not to mention that your printer is the main speed factor: you want good-looking output on a PostScript printer? You'll get 3 or 4 pages per minute. Want fair-looking output on a stupid laser printer? Maybe 6 pages per minute. Want fast output? Use someone else's lineprinter (and look like it, too) or maybe one of those laser lineprinters, whose output is measured in pages per second, and whose cost is measured in $K.] Wayne Folta (folta@tove.umd.edu 128.8.128.42)
sbb@esquire.UUCP (Stephen B. Baumgarten) (01/04/89)
In article <15213@mimsy.UUCP> folta@tove.umd.edu.UUCP writes: >[ No parallel on the Mac to Unix pipes ] >[This lack] cannot really be answered, except by concentrating power >in individual applications, so that tasks commonly performed with >multiple programs can be done in one program. This solution is not as >elegant as pipes, but Mac word processors do everything that you would >have to use about 3 nroff pre-processors to do. This brings to mind another issue, and possible deficiency of the Mac (at least relative to command-line programs). Look at how much time Stuffit spends putting up, taking down, and redrawing its windows. It seems to be a significant portion of the time it takes to "unstuff", especially if there are a lot of little files in the archive. It gets so bad at times that I'm tempted to write a program that just unstuffs an archive, but doesn't display anything on the screen except maybe a spinning watch. One of the things I like about MacCompress is that it just goes ahead and compresses a file (or files) and tells you when it's done. To see what I mean, do a ``multiple add'' in Stuffit of a folder full of text files (of a few K each) using Lempel-Ziv compression. Then tell MacCompress to do the same thing. Big difference, and I don't think it's because Ray Lau is a bad programmer. In answer to the comment above, most Mac word processors don't even come close to what can be done in a Unix environment, even by relative novices. It's just too difficult to build everything into a single application -- and too easy for people running editors under Unix to mark a block of text and pipe it through ``sort'' or ``spell''. Forget about regular expressions (I thank God every day that Microsoft Word at least lets you search for things such as paragraph marks). Of course, it should be noted that programs on the PC suffer from this very same deficiency -- it's not at all Mac-specific. All in all, a command-line interface on the Mac would be useful. Power users could use it, and novices could ignore it. Even though the Mac itself doesn't support multiprocessing in the same way as Unix, the MPW shell does support it's version of pipes, and making this (or something like this) available outside the MPW environment would probably be a good thing. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." cmcl2!esquire!sbb | esquire!sbb@cmcl2.nyu.edu | - David Letterman
amanda@lts.UUCP (Amanda Walker) (01/05/89)
sbb@esquire.UUCP (Stephen B. Baumgarten) writes:
Even though the Mac itself
doesn't support multiprocessing in the same way as Unix, the MPW shell
does support it's version of pipes, and making this (or something like
this) available outside the MPW environment would probably be a good
thing.
Apple certainly seems willing to let other vendors bundle the MPW shell
with their products (such as TMP Pascal II, etc.). Perhaps someone
will do the same thing with some text-processing tools instead of a
compiler. In fact, most UNIXoid preprocessors and filters should port
to MPW pretty quickly, since MPW tools sit in an environment that looks
awfully close to UNIX...
Take something like 'nro' or 'TeX in C', add a PostScript
postprocessor and a tool to send PostScript files to a LaserWriter,
and there you are. The MPW shell is a pretty good editor, with
regular expressions, selection expressions, scripts attached to menus,
and so on.
--
Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net
InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
Calm down; it's only ones and zeros...tim@hoptoad.uucp (Tim Maroney) (01/05/89)
In article <874@lts.UUCP> amanda@lts.UUCP (Amanda Walker) writes: >In fact, most UNIXoid preprocessors and filters should port >to MPW pretty quickly, since MPW tools sit in an environment that looks >awfully close to UNIX... Probably true of filters and preprocessors, but I must take issue with the idea that MPW Shell is close to UNIX. No prompt based program runs correctly under MPW Shell because no distinction is made between input and output text. If you put out a prompt and wait for a command after it, then when the user hits Enter, you will be given the whole text line, including the prompt. The existing software doesn't know to throw the prompt away, and so it will give an unrecognized command error (or worse, interpret the prompt erroneously as a real command and do something not predicted). The MPW Shell is nothing like a UNIX emulator. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I have recently been examining all the known superstitions of the world, and do not find in our particular superstition (Christianity) one redeeming feature. They are all alike founded on fables and mythology." -- Thomas Jefferson
straka@ihlpf.ATT.COM (Straka) (01/05/89)
In article <15213@mimsy.UUCP> folta@tove.umd.edu.UUCP writes: >There are several threads swirling around the Mac interface issue, so I >may be confused, but I think we might need to clarify what we mean by >"command line interface", as somehow opposed to the Mac interface. > >2. Having a UNIX-like shell. > >But issue 2 is involved. Obviously, a shell command-line interface is >useful for certain, concrete reasons. What are they? Maybe we could get >some concrete comments here, beyond "It is faster" (e.g. what is meant >by "it"?). > >At work/school, I have used UNIX on platforms from Suns to Crays. At >home, I have owned an IBM and an Amiga, but I now use Macintosh >exclusively. My observations are: > >1. The shell allows you to "move" faster, e.g. with > "cd /usr/folta/src/proj1". You don't have to move from folder to > folder, as on the Mac. Setting $CDPATH is a real help, too. (minor point) > >2. The shell allows you to have shell scripts, which automate repetitive > tasks. This is the real advantage, but not only repetitive tasks can be automated. The Bourne and Korn shells give you full programmability with control flow constructs, the ability to pass parameters, functions, IPC, recursion, the ability to fake keyboard input where needed (with some restrictions), the ability to modify your OS environment, ... I have seen the shell used as a prototyping environment for entire projects. For quick, effective hacks, it is quite powerful, especially when hacking around automated edits on tabular data, ... For these reasons, I consider the MS-DOS command line interface "All the arcane syntax that UNIX gives you, but with none of the power." > >3. The shell allows you to use pipes. E.g. > "cat x y z | sort | uniq | pr | lpr". Yes, the concept of generalized IO (stdio and named pipes) offers a wealth of options for hacking on data. The uses are not limited to printing either. For instance, I use the 2 following (and not too conceptually hairy, either) shell scripts to log the disk space on my login's file system once per day (from within my .profile), and then plot it out (on request only) on VersaTerm's 4014-graphics emulator. This sort of thing can be incredibly powerful. (note: PARNAME is the name of your login's file system.) ---------------------------------------------------------------------- #rdfout: plot free disk space with time cut -c35-40 $HOME/misc/${PARNAME}rdf.out|plot |td #rdflog: log free space in login's file system if grep "`date '+%h \{1,\}%d'|tr -d "[0*1]"`" $HOME/misc/${PARNAME}rdf.out 1>/dev/null 2>/dev/null then echo else date >>$HOME/misc/${PARNAME}rdf.out df|grep ${1}|tee rdf.tmp;cat rdf.tmp >>$HOME/misc/${PARNAME}rdf.out;rm rdf.tmp fi ---------------------------------------------------------------------- -- Rich Straka att!ihlpf!straka Avoid BrainDamage: MSDOS - just say no!
drc@claris.com (Dennis Cohen) (01/05/89)
You can overcome this and make it more like unix if you remember to select your response to the prompt before hitting "Enter". Yes, I know that it is a kludge; however, it can get unix programs running and keep them running under the shell. Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_!
levin@bbn.com (Joel B Levin) (01/06/89)
In article <7859@claris.com> drc@claris.com (Dennis Cohen) writes: | |You can overcome this and make it more like unix if you remember to select |your response to the prompt before hitting "Enter". Yes, I know that it is |a kludge; however, it can get unix programs running and keep them running |under the shell. Or, if you are really looking for workarounds for prompting programs, respond to the prompt with <return> response <enter> -- No mousing required. /JBL -- UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 INTERNET: levin@bbn.com
tim@hoptoad.uucp (Tim Maroney) (01/06/89)
In article <7859@claris.com> drc@claris.com (Dennis Cohen) writes: > >You can overcome this and make it more like unix if you remember to select >your response to the prompt before hitting "Enter". Yes, I know that it is >a kludge; however, it can get unix programs running and keep them running >under the shell. I've done that; after about a minute you're ready to throw the Mac into the wall. "Kludge" does not go quite far enough. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Our newest idol, the Superman, celebrating the death of godhead, may be younger than the hills; but he is as old as the shepherds." - Shaw, "On Diabolonian Ethics"
nick@ccicpg.UUCP (Nick Crossley) (01/06/89)
In article <34179@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >In article <7859@claris.com> drc@claris.com (Dennis Cohen) writes: >|You can overcome this and make it more like unix if you remember to select >|your response to the prompt before hitting "Enter". Yes, I know that it is >|a kludge; however, it can get unix programs running and keep them running >|under the shell. >Or, if you are really looking for workarounds for prompting programs, >respond to the prompt with <return> response <enter> -- No mousing required. Yes, these ideas both work, but it would be nice to have a way of getting the expected prompt/reply format working. How about a way of setting an 'auto- select' mode (did I just say 'mode'?? :-)) something like this :- printf ("Prompt "); /* Output prompt, leave insertion point at end */ set_auto_insert (); gets (reply); /* Any characters typed are added to selection */ It is rather kludgy, and you need to change the source, but it might still be nicer than forcing the user to remember weird rituals while running the program. Followups redirected to comp.sys.mac.programmer, where this is now more relevant. -- <<< standard disclaimers >>> Nick Crossley, CCI, 9801 Muirlands, Irvine, CA 92718-2521, USA. (714) 458-7282 uunet!ccicpg!nick / nick@ccicpg.UUCP
amanda@lts.UUCP (Amanda Walker) (01/06/89)
tim@hoptoad.UUCP (Tim Maroney) writes:
[stuff about prompts etc.]
The MPW Shell is nothing like a UNIX emulator.
I agree, and I thought I was reasonably careful about what I said, but
let me rephrase: The C programming environment for MPW tools is very
similar to the UNIX C programming environment. For example, you have:
signals
stdio
math
System V memory manipulation
and so on. The discussion that my original posting was a part of was
centered around UNIX-style document processing tools, which for the most
part would be quite easy to port, even with the anomalies that Tim
mentions in how console input is treated, since they are NOT interactive.
I never said MPW was a UNIX emulator...
--
Amanda Walker ...!uunet!lts!amanda / lts!amanda@uunet.uu.net
InterCon, 11732 Bowman Green Drive, Reston, VA 22090
--
Calm down; it's only ones and zeros...bmartin@uhccux.uhcc.hawaii.edu (Brian Martin) (01/08/89)
In article <958@esquire.UUCP> sbb@esquire.UUCP (Stephen B. Baumgarten) writes: >In article <15213@mimsy.UUCP> folta@tove.umd.edu.UUCP writes: >>[ No parallel on the Mac to Unix pipes ] >>[This lack] cannot really be answered, except by concentrating power >>in individual applications, so that tasks commonly performed with >>multiple programs can be done in one program. This solution is not as >>elegant as pipes, but Mac word processors do everything that you would >>have to use about 3 nroff pre-processors to do. > There have been a number of times where I've wanted to drop into a command line interface and type a little Bourne/Korn-shell style script to do a global change to a group of files. For example, before shipping a group of nroff source files to the Mac, for conversion to Word, I run a sed script which replaces EOL chars with SPACE chars when necessary, leaving the blank lines unchanged (so they can be interpreted as paragraph marks). Or I might want to change a filename suffix from ".l" to ".c", with a script such as for i in *.l do mv $i `basename $i .l`.c done Or how about grep '^Subject.*RSG' * */* Really quite simple on a UNIX box, but difficult on the Mac. I also rely heavily on the ability to pipe data between existing tools such as awk, sort, uniq, sed and join for the analysis of large free-text databases. Changing the subject a bit--why aren't regular expressions supported on Mac word processing or database products? Here, I'm referring to the full complement offered by programs such as egrep. It would seem pretty simple to port the "re_comp" and "re_exec" routines from the UNIX system to a Mac program. (The command "mac regex" gets you a short synopsis of these routines.) Some of the software I've developed in the past has used these routines liberally. --- Brian ==== Brian K. Martin, M.D. Department of Psychiatry John A. Burns School of Medicine University of Hawaii and Martin Information Systems, Ltd. 1103 9th Ave., Suite 203 Honolulu, Hawai`i 96816-2403 Voice (808) 733-2003 Fax (808) 733-2011 ARPA: uhccux!bmartin@nosc.MIL UUCP: {uunet,dcdwest,ucbvax}!ucsd!nosc!uhccux!bmartin INTERNET: bmartin@uhccux.uhcc.hawaii.edu
drc@claris.com (Dennis Cohen) (01/09/89)
In article <2969@uhccux.uhcc.hawaii.edu> bmartin@uhccux.UUCP (Brian Martin) writes: >There have been a number of times where I've wanted to drop into >a command line interface and type a little Bourne/Korn-shell style script >to do a global change to a group of files. For example, before shipping >a group of nroff source files to the Mac, for conversion to Word, >I run a sed script which replaces EOL chars with SPACE chars when necessary, >leaving the blank lines unchanged (so they can be interpreted as paragraph >marks). Or I might want to change a filename suffix from ".l" to ".c", >with a script such as > > for i in *.l > do mv $i `basename $i .l`.c > done > >Or how about > > grep '^Subject.*RSG' * */* > >Really quite simple on a UNIX box, but difficult on the Mac. > I don't know about you, but I find this sort of thing very easy to do on the Mac -- use MPW. The wildcards are different and most of the tool names differ, but the tools and capabilities are there. >I also rely heavily on the ability to pipe data between existing tools >such as awk, sort, uniq, sed and join for the analysis of large free-text >databases. > Again, use MPW for this sort of capability. > >Changing the subject a bit--why aren't regular expressions supported on >Mac word processing or database products? Here, I'm referring to the >full complement offered by programs such as egrep. It would seem pretty >simple to port the "re_comp" and "re_exec" routines from the UNIX system >to a Mac program. (The command "mac regex" gets you a short synopsis of >these routines.) Some of the software I've developed in the past has >used these routines liberally. > Regular expressions are supported by Qued/M, MPW, Lightspeed C, and a number of other products. Some simplified expression-matching is provided by MS Word, FullWrite, and other word processors. In general, they aren't provided because the desire for them is rather small compared to the demand for "simplified and intuitive" interfaces. For the users of software development products, such capabilities abound because there was a demand for them -- for users of word processors and databases, the demand hasn't been there. Some simplified pattern matching exists in dBASE Mac and 4th Dimension, but even there, the majority of the users I've talked to don't use those capabilities usually because they say that it's not "Macish" (a great, nebulous term). ** FLAME ON (low heat setting) ** Unix is an extremely powerful environment. I use it a lot and appreciate the flexibility it gives me. I also know that it isn't for the masses because they don't understand it and don't want to take the time to learn a new language and methodology--especially one they find cryptic. Why can't the people on this net realize that we are a somewhat biased sample and not representative of the mainstream Mac market. In most respects we are a vertical market owing to our background and exposure to alternate approaches. We are not even a significant market when you consider that there are probably more copies of MS Word, FileMaker II, MacDraw II, or Excel sold in any two or three month period than there have been copies of LSC sold in the history of the product -- and it is probably the single most successful development product on the Mac. ** FLAME OFF ** Dennis Cohen Claris Corp. ------------ Disclaimer: Any opinions expressed above are _MINE_! (although others of you may share some of them)