Date: Fri, 13 Dec 2002 23:03:17 +0300 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: "Arthur J. O'Dwyer" Message-Id: <3995-Fri13Dec2002230315+0200-eliz@is.elta.co.il> X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 CC: djgpp AT delorie DOT com In-reply-to: (ajo@andrew.cmu.edu) Subject: Re: Bug in command-line globbing References: Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Arthur J. O'Dwyer" > Newsgroups: comp.os.msdos.djgpp > Date: Fri, 13 Dec 2002 12:26:14 -0500 (EST) > > So when I use quotes, I am usually in my mental "Unix mode", and I > expect the quotes to behave as closely to Unix as possible. They do behave close to Unix, but not as close as you expected. I explained the reasons for the differences: they are required to let DOS/Windows users be comfortable with the command-line handling and in particular with native DOSish file names. What you suggest--making \ escape any character including itself--would require doubling every backslash in a file name, which is IMHO a ridiculous requirement for DOS/Windows users. > Wht do you mean, "Some cases of mismatched quotes are actually the > shell's fault"? How much globbing (by which I mean generic "argument > parsing") is done by the shell (by which I mean COMMAND.COM)? My > experience from assembler programming is that COMMAND.COM doesn't > do any parsing of arguments at all; it's entirely up to the client. Please look in versions of COMMAND.COM from latest Windows releases, and you will see that they do know about quotes (they need that for file names with embedded whitespace and other special characters). On some Windows 9X systems, long command lines with unmatched quotes can actually crash the DOS box (due to a bug in COMMAND.COM)--a clear sign that the shell does process the quotes. > A. Sinan Unur points out that > > % test.exe "*"\ hello > > works Yes, this is the recommended solution to such situations. > but it looks like an incredibly flimsy hack to me I fail to see why is this a ``flimsy hack''. The same will work on Unix, for example. > and I wouldn't be surprised if it stopped working in future versions > of DJGPP I would be surprised if this will ever change. There's too much working code and scripts out there that depend on this. >(because the next guy who looks at the globbing code might not > know this hack is out there). Please look in the library sources and point out where do you see the terrible hack which someone would like to take out. I think you will find that there's no such hack, i.e. there's no special code that allows "*"\ and its ilk to do what you want. Rather, it's a simple consequence of the design, namely, that a backslash escapes only the quotes and nothing else, and is not stripped away unless the following character is not a quote. In other words, if some J. Random Hacker would like in the future to remove this ``hack'', he or she will have to redesign the whole thing and then rewrite it from scratch. > In bash or ksh (as the nice folks in comp.unix.misc have informed > me), the following command line does what I want: > > tr -d '.?\\' *.txt > > With DJGPP in MS-DOS, the best I can do is > > tr -d ".?"\ *.txt > > and I've already explained that this just looks bad. You have chosen a design of a program based on Unixy shell behavior. That's why it works on Unix, but only half-works in DJGPP. Should you, e.g., choose " as your escape character, you'd have problems on Unix as well. So I dare to claim that you dislike the DJGPP behavior because you've chosen an unportable design that won't work with any globbing but the strictly Posix one. Personally, I don't see why ".?"\ ``looks bad'', but if you don't like it, the best solution for your problem is to write your own globbing function. The rest of this thread has enough pointers to documentation to let you do that.