Date: Wed, 09 Sep 2026 18:56:00 +0200 (CEST)
From: Jarle Greipsland <[email protected]>
Message-ID: <[email protected]>
| I will claim that having the filelist function return only one
| filename out of (potentially) many matches is more than a slight
| alteration of the way the function works.
Yes, I agree.
| Just because some fat-fingered co-worker managed to drop an
| unfortunately named file into a directory.
Yes, I agree, the quotes should be there.
| OTOH, as implemented, the filelist function does not handle files
| with single quotes in their names, and this might be a bigger
| obstacle to using this function "for real".
That was the whole point of this example - I'd never use a function
like that "for real" in anything general purpose.
You'd need to go back and find the original thread (which had something
to do with rc.d files, if I remember it, being provided from pkgsrc,
before Edgar renamed this part of that thread to be about shell quoting)
to get the context.
That example was just a brief (not ever intended to be used for anything)
way to illustrate how one can deal with potentially dangerous file names in
an arg list, with, in this case, the caveat that there is no need to
handle filenames with single quotes in their names - and given the context
was rc.d/* script names, that would probably not be an unreasonable
limitation).
Doing it properly requires a much more complex quoting function than
just
printf "'%s'" "${name}"
though, one too complex for that example (in the places I actually use that
kind of thing, I have a function which does the quoting, properly, it was
just too much for this example).
| Besides, there are probably better ways to arrange the processing
| of files in a directory.
Indeed there are. However, back in the original context, the rc.d/*
files, what matters is that the order of the resulting list needs to
depend upon the content of the files, rather than their names (as in
the original System III (or System V, whichever it was) similar design
where the file names provided the ordering, leading to 00me-first
01i-am-second ... type naming, which is a maintenance nightmare when
a new script needs to be inserted between 00xxx and 01xxx leading to
000new-name attempts, which fails as that fits before 00xxx usually,
and then other variants, 00~00new-name works (probably) until yet
another needs adding between the 00xxx and this one ... otherwise
everything needs to be renumbered when new scripts are added.
Leaving gaps in the original numbering helps, but only until the
gap fills, and you don't get N new names between one and the next,
where N is the original gap, just log(N) (log base 2 in practice)
as each new name halves the size of the gap, even for big gaps,
say 100 200 300 ... the new files are ordered like 150 125 112 106
103 and (101 or 102) and after just 6 new files, the 99 slot empty space
has run out (that is, given the appropriate requirements, which Murphy's
law says will happen), and there's no available number for the next one.
Make the original gap 1000, and you can run out after 9 insertions.
This all leads to the desire to process and order the files in sh code
instead of the "probably better way" which almost certainly exists in
different examples, without that particular ordering requirement.
Hence, the example, of (assuming constrained file names, but without
breaking if the constraint is violated) how it can be done, and cheaply.
None of this was ever intended to be executed, just illustrating a
technique which could be used if the desire was ever there.
kre
