On 05/12/2016 16:49, Steve D'Aprano wrote:
On Mon, 5 Dec 2016 10:42 pm, BartC wrote:
So if someone types:
> X A B C
You would expect X to be launched, and be given arguments A, B and C.
Would I? I don't think so.
Even the DOS prompt supports some level of globbing. Its been a while since
I've used the DOS prompt in anger, but I seem to recall being able to do
things like:
dir a*
to get a listing of all the files starting with "a". So *something* is
treating the * as a special character. In Linux and Unix, that's invariably
the shell, before the dir command even sees what you typed.
In DOS, it might be the dir command itself.
Yes, it has to be, as there is probably no space to first construct an
in-memory list of all the files.
The disadvantage of the DOS way
of doing this is that *every single command and application* has to
re-implement its own globbing, very possibly inconsistently. That's a lot
of duplicated work and re-inventing the wheel,
Which will need to be done anyway. Expansion of filespecs with wildcards
may need to be done from inside a program.
On Windows that involves calling FindFirstFile/FindNextFile (which takes
care of wildcards for you), and on Linux it might be opendir/readdir
(which doesn't; you have to call fnmatch to accept/reject each file).
(I had to port such code recently across OSes for my language; on both
systems, dirlist(filespec) returns a list of files matching the wildcard
specification provided. No shell expansion is needed!)
The Unix way is far more consistent: applications typically don't have to
care about globbing, because the shell handles glob expansion, environment
variables, etc.
It's not consistent because program P will sometimes see * and sometimes
a list of files. On Windows P will /never/ see a list of files if the
start point is *. Not without a lot of intervention.
And I've already posted a long list of reasons why Linux shell's
behaviour is undesirable, as you want to literal argument, or you want
to do something with the filespec that is different from what the shell
will do, or you want to do it later (perhaps the files question DON'T
EXIST until halfway through the program).
OK I'm just thinking up more reasons why I don't like Linux shell's
behaviour.
You wouldn't expect any of them to be expanded to some unknown number of
arguments.
Actually yes I would. If they could be interpreted as file names with
globbing or environment variables, that's exactly what I would expect.
If the syntax is:
program filespec
or:
program filespec file
how do you tell whether the last file in an argument list is the
optional 'file', or the last file of the expansion of 'filespec'?
So yes, I would expect that if I said
dir a*
I would get a listing of all the files starting with "a", not just the
single file called literally "a*".
So what does 'dir' do then; just print?
Since it sounds like:
echo *.*
would do the job just as well! (If 'echo' is a program that just lists
its input.)
Fine. Just escape the damn thing and do whatever you like to it.
I'm not the one running the program. Perhaps you don't know how stupid
users can be.
The input is a PATTERN; I want to process it, and apply it, myself.
When you double-click on a .doc file,
Are we still talking about a console or terminal here? Any filenames
displayed as part of the dialogue (result of ls or dir for example) are
usually not clickable.
and Windows launches Word and opens
the file for editing, do you rant and yell that you didn't want Word to
open the file, you wanted to process the file name yourself?
GUIs are different.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
