Bored to day since it's -20 and I don't want to work outside.
On 12/05/2016 12:24 PM, BartC wrote:
>> If it sees "*", it will try to open a file named "*".
>
> And people still say that the way Windows works is crazy!
>
> That's a valid
>> filename in Unix, but it should be avoided.
>
> No, it should be prohibited, if the file API and/or shell assign special
> significance to it.
Why? What does it matter to the file system what characters are in the
filename?
>
>> I don't understand your concern regarding Unix shell scripting syntax.
>> On Windows, are you as troubled that environment variables such as
>> %USERNAME% get expanded by cmd.exe, but not by CreateProcess?
>
> No, because I never use %USERNAME%, and it is obviously something
> associated with Windows' Batch language which I hardly ever use.
cmd.exe *IS* the the "Windows' Batch" language. So if you use cmd.exe,
you use this "Batch" language all the time.
> Not like file wildcards, which I use all the time, and don't associate
> them exclusively with a shell.
>
>
> I also never expect any parameter that contains ? and * to be expanded
> then and there to whatever list of files there might happen to be. Maybe
> the files haven't been created yet, maybe the parameter has got NOTHING
> TO DO with filenames.
>
> (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
I can't think of any way to do that in a consistent way. I can see it
working for the simple cases. Must have quite a bit of logic in rename
to handle all the corner cases.
Such a syntax, even with quoting, would be highly unusual to see in the
Unix world. I think I'd rather just use a simple loop and have the
rename be explicit so I know it's working (and yes I do this all the
time) as I expect it to.
> since, if the user forgets the second parameter, and there were two .c
> files, it would think I wanted to rename one .c file to another.)
>
> 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?
>
> >station ?LBC
>
> 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.
I would expect in this case that the "station" program would return an
error, something like:
Error! Cannot find station "ALBC"
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. Or change my logic
to not require this ? character (if it was part of all identifiers we
can drop it safely).
>
>> Every command-line shell that I've ever used is also a quirky
>> scripting language.
>
> 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.
--
https://mail.python.org/mailman/listinfo/python-list
