Composition is completely hamstrung by a simple syntactic flaw: the begin- and end-delimiters for all the quoting forms are indistinguishable. So if I write:
`ls `pwd`/files`the shell cannot determine whether the second occurrence of the backtick (`) character is ending the command or starting a sub-command.
This wouldn't be so terrible if there were a reasonable form for local binding so you could write your shell commands in A-normal form.
6 comments:
It's not all that bad. Try
$(ls $(pwd)/files)
Jeremy
You have to remember that everything is by textual substitution, so:
`ls \`pwd\'/files`
I like the $() notation -- I'd never seen that.
I was going to suggest the $() trick, but Jeremy beat me to it.
I will point out, though, that this is only a partial solution, since it only works on certain shells. Specifically, this works on bash and zsh, but not on sh, csh, or tcsh (at least in the versions currently installed on the CCIS Solaris network).
So, yeah -- I agree with Dave. Unix quoting is a pain in the rear. This is one of the reasons I normally cite when I argue that programming in {ba,z,c,tc,}sh doesn't scale.
Don't blame unix(at least the bell guys). That's a bournism.
The research unix/plan 9 shell rc deals with command expansion using the following syntax
`{ls `{pwd}/file}
rc always deals with quoting in a uniform way too. Check out Tom Duff's(yes the Duff's device guy) paper.
I want to emphasize that both command expansion and quoting have been solved problems since the late 80's or so. The gnu folks just never caught on. They were too busy adding weird long options to bash.
To extend what npe said, a version of the Plan9 shell, rc, is available for Unix. I have been using it for about 10 years. (Gosh has it been that long?) My exceedingly long command lines have become legend at work, partly because of the ability to deeply nest quotations.
Thanks for sharing amazing information keep posting. cafeale.se
Post a Comment