On 08/12/2016 03:41, Steven D'Aprano wrote:
On Thursday 08 December 2016 12:15, BartC wrote:
That's all. I know the value of keeping things straightforward instead
of throwing in everything you can think of. The file-matching is done by
WinAPI functions.
So you're happy with the fact that there are legitimate file names that your
program simply has no way of dealing with?
Perfectly. Such names are illegal on its home OS which is Windows, and
ill-advised elsewhere.
Plus you're missing the fact that these are /functions/, not user
interfaces, and are entitled to use whatever scheme they like to express
patterns of filenames. Since it has few ambitions, it just uses
Windows-style wildcards.
Thank you for making my point for me! If you leave the implementation of
metacharacter expansion
This is some feature most of my users had never heard of and never cared
for. It only appears to exist in the CLI of some shell or other that
runs on Linux.
Python's fnmatch lib is a good example. It has, or at least had, no support for
escaping metacharacters. Anyone relying on Python's fnmatch and glob modules
alone for globbing will be unable to handle legitimate file names.
That was a good choice. This stuff might be OK for interactive user
input in a shell. It might even be OK for sticking in a script file in
the same language as that shell
But it DOESN'T BELONG in a general purpose library, written in a
different language, and nothing to do with the language syntax used by
that shell. It might *opt* to include some well-known elements (such as
? and *), but that is a choice.
If you want full shell functionality within a program, then just invoke
that shell!
Reading that post again, you presumably meant either *.* used to match
all files (with an embedded "." in Linux, with or without in Windows;
another difference), or *.* used to match a specific file called *.*.
Correct.
It doesn't matter whether metacharacters are expanded by the shell or the
program itself, there needs to be an escaping mechanism for those cases where
you want the metacharacters to be treated literally.
How do you write a specifier for filenames that consist of any
characters but which must be in alphabetical order? (eg. 'forty' but not
'fifty')
My point is it's easy to come up with a requirement that can't be
handled. (If that one can, then I'll just think of a different one!)
(Here's one solution if I desperately needed that feature:
http://pastebin.com/wjzu9L6L. Probably a Python one-liner given an input
list of filenames.)
So presumably your dirlist() command can distinguish between the file called
literally "*.*" and the file spec "*.*" that should be expanded,
No. I won't support that (not unless it's supported by Posix's
fnmatch()). Because it's the thin end of the wedge. I can show a few
lines of code and then you will say, Ah, but what about this...
And I first used this function in early 90s I think, I don't recall it
ever not working.
If you can't use it to specify a file called literally "*.*", then its not
working.
Presumably your solution requires some intervention to turn *.* into
something that is escaped so that it will be matched literally. But
then, the same kind of intervention can be used to instead call
dirlist_special():
function dirlist_special(pathandfile)=
if checkfile(pathandfile) then
return (extractfile(pathandfile),)
else
return ()
fi
end
print dirlist_special("*.*")
And of course your program is also capable of variable and arithmetic
expansion, right?
Um, dirlist() is used within a language, of course it can do all that.
If you mean within the file-pattern string submitted to dirlist, then I
don't even know what that would mean.
I showed you an example in another post:
[steve@ando ~]$ export base="thefile"
[steve@ando ~]$ ls -l "$base$((1000 + 234))"
-rw-rw-r-- 1 steve steve 0 Dec 8 10:51 thefile1234
Of course it is silly to write 1000 + 234 as a literal constant like that, but
either or both of those could just as easily be variables.
The point here is not that *you* should build a calculator into your version of
ls.
I don't have to do anything of the sort. I'm quite happy that the shell
does that sort of esoteric stuff which wouldn't occur to many people to
want to do (if they even know about it), and doesn't interfere with the
basics.
Yes, I've written applications that use a command line, even GUI ones,
which allows variables and expressions. But that is relevant in the
context of that application and not outside .
Take all the programs that you run on Linux, /including GUI programs/.
In all the situations where it requires a file-name and lets you type it
in (not just from the shell command line, but within a program or from a
GUI entry box), does it let you do all this meta-character and
meta-expression stuff that you're on about?
If so, please tell me how to define '$base="thefile"' from inside
LibreOffice, and how to make use of it in the file dialog entry box.
If not, then what you're arguing about is meaningless.
For example, a quick and simple way of backing up a file with a date stamp:
steve@runes:~$ cp alloc.txt{,-`date +%Y%m%d`}
steve@runes:~$ ls alloc.txt*
alloc.txt alloc.txt-20161208
Pretty good. Except I just tried that method in Firefox to save a page:
c.html{,-`date +%Y%m%d`}
and it worked - sort of. I just got a saved page called:
c.html{,-`date +%Y%m%d`}
Does this mean Firefox is broken?
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
