Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site houligan.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!akguc!codas!peora!ucf-cs!novavax!houligan!dave@smaug.UUCP From: dave@smaug.UUCP (Dave Cornutt) Newsgroups: net.unix Subject: Re: gripes about /bin/sh AND /bin/csh Message-ID: <44@houligan.UUCP> Date: Fri, 13-Jun-86 16:20:50 EDT Article-I.D.: houligan.44 Posted: Fri Jun 13 16:20:50 1986 Date-Received: Tue, 17-Jun-86 21:04:06 EDT Organization: Gould Electronics, Ft. Lauderdale, Florida. Lines: 138 Relay-Version: version B 2.10.1 6/24/83; site houligan.UUCP Path: houligan!novavax!ucf-cs!peora!codas!akguc!akgua!gatech!seismo!harvard!husc6!panda!genrad!decvax!bellcore!ulysses!burl!clyde!cbosgd!osu-eddie!karl From: karl@osu-eddie.UUCP Newsgroups: net.unix Subject: Re: Gripes about /bin/sh AND /bin/csh Message-ID: <1913@osu-eddie.UUCP> Date: Fri, 6-Jun-86 09:27:04 EDT Article-I.D.: osu-eddi.1913 Posted: Fri Jun 6 09:27:04 1986 Date-Received: Fri, 13-Jun-86 10:41:12 EDT References: <931@uwvax.UUCP> Organization: OSU Lines: 54 Keywords: RTFM. In article <1913@osu-eddie.UUCP>, karl@osu-eddie.UUCP writes: >In article <931@uwvax.UUCP> pfeiffer@uwvax.UUCP (Phil Pfeiffer) writes: >>I'm posting this message in reponse to a request from a fellow UW student. >>This comes from a novice Unix user. Maybe some other people in the >>unix community could prove to me that these gripes are really non-gripes. > >I suspect so. > >>I'm trying to do some extensive rapid prototyping in shellish right now... >>...First, there's the bit about brain-damaged >>quoting (or, non-quoting) of metacharacters. > >If you don't understand the quoting habits of csh (or sh), you haven't >read the manual pages on them - the descriptions are really quite >clear, compared to a lot of UNIX documentation. Single chars can be >quoted with a backslash; strings can be single-quoted to prevent any >further interpretation; and double-quoted to allow filename >substitution without meta-char substitution. In csh, variable substitution takes place inside double-quoted string ALWAYS, even if the $ sign is backslashed. > >>I'm sure a lot of you already >>know that the ability to use backquote to expand certain command strings >>just isn't there. > >Yes, it is; backquoted command strings are supported by both sh and csh. >If it weren't, I couldn't issue a command like > ls -l `find . -size +100 -print` >Read the manual. What the manual doesn't tell you is that backquoting doesn't work with some built-in csh commands (at least not in our version). For example, I wrote a program called "mkumask" that you could give a string like "rw-rw-r--", and it would print out the value to set the umask to to get those default permissions on newly-created files. I figured I could do a command like this: umask `mkumask rw-rw-r--` and it would set my umask for me. Guess what? It chokes. But if I do it like this: $foo = `mkumask rw-rw-r--` umask $foo it works. Apparently there is a problem expanding backquotes in some built- in commands. Which commands are built-ins? You have to wade through the lengthly manual section for csh to find out. (And they're not all listed in the same place.) > >>'Twould be useful if one could abbreviate commands as >>variables to make one's code more legible, a la lisp. > >Aliasing is supported by csh. Sh does it with plain variables. Read >the manual. True enough. Phil: you can create a command alias by doing something like this: alias For example, if you're used to VMS and you constantly type "rename" in- stead of "mv", you can do this in your .cshrc: alias rename mv and every time you type "rename" as a command name, csh will translate that to "mv". If you type "alias" without any arguments, it will list your current aliases. If you want to kill an alias, type "unalias ", and the alias called "name" (if there is one) will no longer be in effect. > >>That's irritating. What's really irritating, however, is the inability to >>open and read multiple files from the shell. I mean, even RSX-11M's CSI has >>this! > >Sourcing of other command files is supported by both csh and sh. Read >the manual. That isn't what he meant. What Phil wants (me too) is some capability to open a file in a sh/csh script and read a line at a time into a variable, like this: open xyz while ( ! eof(xyz) ) read xyz $line_from_file <...do stuff with data...> end close xyz Neither sh nor has any such capability. (Ksh might, but I don't have access to that beast.) Note that this isn't the same as $data = `cat `; it's difficult to get the individual lines, csh insists on parsing it up into words, and if the file is large, you run out of memory. There are klugey ways of getting around this, but why put up with a kluge? Bourne and C shells need some sane way to open and read/write files in a script. > >>The requirement was as follows: ... > >After reading what you say you wanted to do (sketchy though it was), >it seems to me you worked at it far too hard. You're not familiar >with the tools available to you. RTFM and make sure you know how >sharp your tools are before you pick them up, or you'll find yourself >with cut fingers. > >In case you haven't notice the recurring refrain in all of the above >response, it is this: > > Read the manual. >-- >Karl Kleinpaste Yeah, and we all know how much fun it is reading that FM when you don't really know what's going on, and all you get when you ask for help is "why don't you go away and read this nice manual and leave me alone?" Nearly everyone is aware that the UN*X manuals are hopeless when used as tutorials, so in lieu of the existience of a suitable training manual, we just have to pass on our accumulated, hard-earned knowledge person-to- person. We all know that there are jerks that post stuff to the net just so they can find someone to do their work for them, but this doesn't sound like one of those cases. Lighten up, the guy's trying to learn. Dave Cornutt Gould Computer Systems Ft. Lauderdale, FL "The opinions expressed herein are not necessarily those of my employer, not necessarily mine, and probably not necessary."