peter@ficc.ferranti.com (Peter da Silva) (02/27/91)
In article <5615@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: > This seems to be a trivial and slightly amusing example of the problems > of standardizing switch notation with a legal filename character. Better than standardizing on unadorned keywords for switches. Try deleting a file named "all" on AmigaDOS. The problem here is that there are no spare characters you can type into the shell that aren't legal in UNIX file names. This is true on many recent operating systems, as the advantages of files named "Joe's Report Part #1" have become obvious. (what does this have to do with comp.arch?) -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
peter@ficc.ferranti.com (Peter da Silva) (03/01/91)
In article <KENW.91Feb25170431@skyler.arc.ab.ca>, kenw@skyler.arc.ab.ca (Ken Wallewein) writes: > As a trivil but amusing example, the other day I had a file whose name > started with '-'. There was no way to tell programs which expects shell > globbing that "this is not a command option; this is a filename". command options-and-arguments -- filenames-only If the command wasn't written to support this syntax, blame that particular program: this has been a standard for years. There are badly written programs in program-does-globbing systems too. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?" Making programs do globbing is like making them handle expose events.
jesup@cbmvax.commodore.com (Randell Jesup) (03/05/91)
In article <KLR9W53@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Better than standardizing on unadorned keywords for switches. Try deleting >a file named "all" on AmigaDOS. Delete "all" If I had the option of redoing AmigaDos from ground zero (which I don't, we're stuck with a lot of Tripos-derived conventions), I would use a convention like Stratus VOS uses, where keywords always have - in front of them (-all, for example). You would still have to quote it, but it becomes more obvious that it's something you should consider quoting. In this case, it would be Delete "-all". >The problem here is that there are no spare characters you can type into the >shell that aren't legal in UNIX file names. This is true on many recent >operating systems, as the advantages of files named "Joe's Report Part #1" >have become obvious. Yup. Though you are left with a few illegal characters in filenames, like the directory separator ('/' in unix/amigados). Spaces in particular are good to have, especially if people are largely interfacing via GUI's. Having spaces in filenames kills shell-globbing to a large extent, or requires it to quote the arguments itself. >(what does this have to do with comp.arch?) I dunno. Software discussions often start there, especially when the interaction between software and hardware is involved, or when something wanders over to software architecture (it's comp.arch, not comp.hw.arch, not comp.cpu.arch - perhaps it should be split). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jesup@cbmvax.commodore.com (Randell Jesup) (03/05/91)
In article <1991Mar3.020451.5596@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes: >There is a convention that a "--" terminates command options. This is >how you can do an "rm -- -ha.ha" without rm complaining. ... >Again, read the convention explained above. This convention is >explained in INTRO(1) of most UNIX manuals. Unfortunately, the user must know in advance if a glob will result in -xxx filenames BEFORE invoking the command, or must always use -- on all command lines. What would happen someone created a file named -r in a directory where you often delete some files with *, or *.c, or whatever? Or -rf? There are all sorts of other nasty possibilities that you can't know about unless you do the globbing once to see which files it matches. BTW, according to the man page I get for rm, it doesn't follow your standard: it wants rm - -ha.ha. >Not that mv does this now, but globbing would pass the unaltered >pattern to the program as an argument, if there are no matches. i.e. >if there are no compress* files, then mv could be clever about it, >because it would be passed the pattern compress* as an argument. What if there was a match? The point is that it's an output spec, not an input one, and therefor shouldn't be matched against existing files. You could design an interface where the shell globbed, but preserved the original argument so the program could pick. That means you may spend a lot of cycles/disk-accesses to glob arguments that don't need it. >As I mentioned before, all the shells I know of, allow you to turn off >globbing. An implicit admission that shell globbing can get in the way at times. It's painful to turn it off just because you want to run a specific command. Also, we're talking more about which design is better (on their own merits), not whether you can at this date retrofit Unix to have this be the default. That's why we're not discussing this in comp.unix.shells. (BTW, I'm sending followups to comp.os.misc). You can get around most any annoyance with enough work, quoting, etc. However, which is better for the user? This is why I reject the arguments that making calls to a system globbing function is too much work for programmers: yes, it is (a very little) more work. However, I think it produces a far better and easier to use interface for the user of the system. It also makes it easier to have a richer globbing language (more than merely * and ?, you can have more RE's - but if you do shell-globbing, you'll end up with command lines that look a bit like Lisp code because of all the quoting and escaping). -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
ccplumb@rose.uwaterloo.ca (Colin Plumb) (03/06/91)
> In article <KENW.91Feb25170431@skyler.arc.ab.ca>, kenw@skyler.arc.ab.ca (Ken Wallewein) writes: >> As a trivial but amusing example, the other day I had a file whose name >> started with '-'. There was no way to tell programs which expects shell >> globbing that "this is not a command option; this is a filename". peter@ficc.ferranti.com (Peter da Silva) wrote: > > command options-and-arguments -- filenames-only > > If the command wasn't written to support this syntax, blame that > particular program: this has been a standard for years. There are badly > written programs in program-does-globbing systems too. Actually, I find that 'command ./filename' works very well, and does not require much intelligence in the command's option parsing. Yes, "--" is a standard and should probably be supported, but I've never seen the need unless you use options that can begin with "." or "/". -- -Colin
rwa@cs.athabascau.ca (Ross Alexander) (03/06/91)
jesup@cbmvax.commodore.com (Randell Jesup) writes: [....] > Unfortunately, the user must know in advance if a glob will result in >-xxx filenames BEFORE invoking the command, or must always use -- on all >command lines. What would happen someone created a file named -r in a >directory where you often delete some files with *, or *.c, or whatever? >Or -rf? There are all sorts of other nasty possibilities that you can't know >about unless you do the globbing once to see which files it matches. Since you use the words `must', `can''t', and `always', I am forced to disagree. Use of the `./*' form of the filename glob eliminates this little trojan. It's always available (unlike `--') unless, of course, you're in the truly pathological case of a . directory without read perms, it's simple, it's been around since donkey's years. I only wish there was really as much concern for pathological conditions as you posit. BTW, isn't this whole thing in the FAQ? More ignorance of globbing/quoting has been spewed around via this thread than I've seen in a long time. -- -- Ross Alexander rwa@cs.athabascau.ca (403) 675 6311 ve6pdq "Oh, I know it's a penny here and a penny there, but look at me. I worked myself up from nothing to a state of extreme poverty." --Groucho Marx
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (03/06/91)
In article <19503@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > Unfortunately, the user must know in advance if a glob will result in > -xxx filenames BEFORE invoking the command, or must always use -- on all > command lines. What would happen someone created a file named -r in a > directory where you often delete some files with *, or *.c, or whatever? Fact: Any path that doesn't start with / can be prepended by ./ without change. (Actually, I don't like this separation into cases; there are many situations where it would be convenient to have a single character that means go back up to root, *anywhere* in a filename. Then doubled slashes wouldn't be a problem, and you could prepend ./ no matter what.) In any case, if you want the shell to do this for you, no problem. > BTW, according to the man page I get for rm, it doesn't follow > your standard: it wants rm - -ha.ha. That is generally regarded as a bug. Keith Bostic says that BSD 4.4 will fix such things. > What if there was a match? The point is that it's an output spec, > not an input one, and therefor shouldn't be matched against existing files. Exactly. Therefore it is not shell globbing. It is pattern matching. That's what regexp libraries are for. > >As I mentioned before, all the shells I know of, allow you to turn off > >globbing. > > An implicit admission that shell globbing can get in the way at times. > It's painful to turn it off just because you want to run a specific command. Be serious. "*". > You can get around most any annoyance with enough work, quoting, etc. > However, which is better for the user? Indeed, is it better to have a single, uniform interface that works for everything users want to do (except find and mvm, and then simple quoting suffices)---or to give users what will invariably feel like an inconsistent interface since programmers will have different opinions on what should be globbed and what shouldn't? > However, I think it > produces a far better and easier to use interface for the user of the > system. Prove it. Nobody comes up with any answer to this except multiple-file rename, and mvm handles that perfectly. > It also makes it easier to have a richer globbing language Be serious. It is easier to change a library routine and recompile all your programs (and don't pretend that shared libraries are used on most systems), or to change the shell? Has it occurred to you that two users might want different globbing conventions? All they have to do now is change the shell. In your world, they would have to change every single program that ``understands'' globbing. Can't you see why modularity is better? ---Dan
jesup@cbmvax.commodore.com (Randell Jesup) (03/06/91)
In article <1991Mar5.171819.10543@watdragon.waterloo.edu> ccplumb@rose.uwaterloo.ca (Colin Plumb) writes: >Actually, I find that 'command ./filename' works very well, and does >not require much intelligence in the command's option parsing. Yes, "--" >is a standard and should probably be supported, but I've never seen the >need unless you use options that can begin with "." or "/". The problem is (as I stated before, and was misunderstood) that globbing (at least all I've seen) do not force ./path if you don't specify it. So, as I said, you must know what files are going to matched by the glob before you do it. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
peter@ficc.ferranti.com (Peter da Silva) (03/08/91)
In article <19553@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes: > The problem is (as I stated before, and was misunderstood) that > globbing (at least all I've seen) do not force ./path if you don't > specify it. So, as I said, you must know what files are going to matched > by the glob before you do it. Or get into the habit of typing "./*". It's only one more character than "#?" anyway... Also considering "#?", shell globbing would have avoided all the complaints about AmigaDOS not using UNIX-type wildcards. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"