On 05/12/2016 19:48, Michael Torrie wrote:
Bored to day since it's -20 and I don't want to work outside.
On 12/05/2016 12:24 PM, BartC wrote:
(For example, in Windows:
>ren *.c *.d
Rename all .c files to .d files. None of the .d files exist (or, because
of the point below, some isolated .d file exists). I wouldn't be able to
emulate such a command under Linux, not without writing:
rename *.c "*.d"
or even:
rename "*.c" "*.d"
Wow. Does that actually work? And work consistently? How would it
handle globs like this:
renamae a*b??c*.c *.d
That's not really the point, which is that a parameter may use * and ?
which, even if they are related to file names, may not refer to actual
input files in this directory. Here, they are output files. But this is
just one of dozens of reasons why automatic expansion of such patterns
is not desirable.
(And yes sometimes it works, for simple cases, and sometimes it screws
up. But it is up to the program how it defines its input and what it
will do with it. It shouldn't be up to the shell to expand such names in
ALL circumstances whether that is meaningful to the app or not.)
But that leads to another weird behaviour I've just observed: if a
parameter contains a filespec with wildcards, and there is at least one
matching file, then you get a list of those files.
However, if there are no matching files, you get the filespec unchanged.
That's true for many shells (but not zsh by default which errors out).
Now, what is a program supposed to with that? It seems it has to deal
with wildcards after all. But also some behaviours can become erratic.
This program asks for the name of a DAB radio station:
Again, it doesn't really matter. If the program was looking for
filenames, the program will try to open the file as given ("a*.txt") and
if it succeeds it succeeds, if it fails it fails. The program need not
care. Why should it?
Really, the program should just fail? It seems to me that the program is
then obliged to deal with wildcards after all, even if just to detect
that wildcards have been used and that is reason for the error. But my
example was how that behaviour can stop programs working in random ways.
Fine, the input is ?LBC (which is an actual station name where I live).
But then at some point a file ALBC comes into existence; no connection.
Now the same line gives the input ALBC, to perplex the user!
Why would a file come into existence? I thought you said it refers to a
station identifier. No wonder you have such confused users if you're
creating files when you should be opening a URL or something.
The file is irrelevant. It's just a bit of junk, or something that is
used for some other, unrelated purpose.
The important thing is that creation of that file FOR ANY REASON could
screw up a program which is asking for input that is unrelated to any files.
I would expect in this case that the "station" program would return an
error, something like:
Error! Cannot find station "ALBC"
And that's the error! But how is the user supposed to get round it? It's
an error due entirely to unconditional shell expansion of any parameter
that looks like it might be a filename with wildcards.
If station ids were supposed to start with a wildcard character, I'd
probably have to make a note in the help file that the station
identifiers have to be escaped or placed in quotes.
I've no idea why that station starts with "?" (it appears on the station
list, but have never tried to listen to it). But this is just an example
of input that might use ? or * that has nothing to do files, yet can be
affected by the existence of some arbitrary file.
And somebody said doing it this way is more secure than how Windows does
things!
It seems shell language authors have nothing better to do than adding
extra quirky features that sooner or later are going to bite somebody
on the arse. Mainly I need a shell to help launch a program and give it
some basic input; that's all.
I think you'd quickly find that such a shell would be very non-useful.
For about five minutes, until someone produces an add-on with the
missing features.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
