Re: ls.1: incorrect -O flag description
On Thu, Oct 10, 2024 at 21:37:15 +0200, tlaro...@kergis.com wrote: > The -O (not a POSIX one) flag seems incorrectly described in the manual > page. > > What it does (from a cursory look at the sources, matching the result > of testing), is simply not displaying a supplementary information > about the directory traversed when going recursive. > > It does not output only leaf (filenames not directory). This is only > the "headline": "\ndir:\n" that is not displayed. > > Just try: > > $ ls -OF > > for example (and combine with -R). > > What was the intention of the flag? To have an output with just the > names (including directories) without the formatting about the newline > and the dir? revision 1.71 date: 2014-02-20 22:56:36 +0400; author: christos; state: Exp; lines: +18 -8; Add -O (only leaf files) and -P (print full path), from tls@ Seems buggy too $ mkdir -p 1/2/3/4 $ touch 1/2/200 $ find . . ./1 ./1/2 ./1/2/3 ./1/2/3/4 ./1/2/200 $ ls -RPO ./1 ./1/2 ./1/2/200./1/2/3 ./1/2/3/4 Can you file a PR, please? TIA. -uwe
Re: interactive shell detection in shrc
Date:Thu, 10 Oct 2024 09:16:08 -0700
From:"Greg A. Woods"
Message-ID:
| As I wrote in my other message yesterday I've given up entirely on
| trying to test for interactivity without using $-.
Yes, I saw that, and I think that's the right approach.
| I have discovered (by serendipity, having been reading the original Ash
| code to verify that it was setting $- with 'i' when necessary) that 's'
| is also set when the shell is reading from stdin, so for it testing for
| 's' in $-, and verifying stdin is a tty would also work to identify
| interactivity.
Perhaps, but I suspect that's considerably less portable than just
using -i ... esp as shells have now been directed to include 'i' in $-
when they consider themselves interactive. Do be aware that "interactive"
has a special meaning to the shell, it alters the way it works iternally,
particularly in relation to various errors. It's not just related to
when it is dealing with a human rather than a script.
| BTW, I see the original Bourne shell also tested stdin and _stdout_ when
| deciding if it was interactive or not. The change to test stderr must
| have come from AT&T Ksh.
Probably. I disagree with a lot of what ksh changed, but that one was
correct, it allows things like
sh | tee output
to continue to act as if one had just run
sh
except a copy of all the output is saved for later (except
stderr, ie: error messages, so the saved output isn't
cluttered with odd "typo: command not found" and stuff,
which for some of us is a big help!)
| Ah ha! I had forgotten about how '-c' works with extra arguments!
I suspect that most people never knew.
| Even more fun the third argument can look like an option letter, but
| still just ends up in argv[0]:
|
| $ sh -c 'echo $0' -i
| -i
|
| This is different from how rsh and ssh work.
Not really - what's different is how -c works. Most people still
believe that -c is like (say) the awk -V option, or cc -D (or -I)
where the option needs extra data, which is either immediately after
the 'V' (or D or I) in the same arg, or if that char is the end of
the option arg (just "-V") then the following arg.
But that's not how -c works at all, in getopt style usage, the options
to sh would be (not including all of them, and ignoring + variants)
"abcefo:svx"
'o' is the only one which needs extra data. What -c does is set a flag
which alters the interpretation of the first remaining arg after the
options are finished. So in your example 'echo $0' isn't an option
(doesn't start with '-') so the options end just before that one (you
could also use '--' between the -c and that string if you wanted).
Once the options are done, everything that follows is just a regular arg,
even if it starts with a '-', so there's nothing special there with the '-i'.
Note that usages like
sh -c -x 'echo $0'
or
sh -cx 'echo $0'
work fine, and always have (well, ignoring shells with bugs, which some
of them have had in this area, as not even all shell authors really
understood the way this worked, once anyway).
| This part confuses me The manual suggests '-a', '-o', and
| parenthesis can be used to create expressions of arbitrary length and
| complexity, and surely I've done so for decades with multitudes of
| implementations with nary a problem.
Then you've been lucky, or have learned the tricks that people have
used to avoid (some of) the issues for ages. But I agree, our man
page more or less had the minimal possible change done to it, almost
just as a sop to POSIX usages - the whole thing (or at least a significant
part of it) needs to be rewritten, so we stop giving people the wrong
impression.
Eg: you'd expect that
test "$x" = "$y"
should tell you whether $x and $y are equal or not, and in any modern
test it does, always (as everyone, I hope anyway, obeys the POSIX rules
for the cases specified there). But not in the past, which has led
to scripts mostly doing things like
test "x$1" = "x$y"
and making test waste time comparing the (known equal) first
character, before going on to the rest of it.
That's because in old versions of test, if you had x='(' y=')' and
used the first version, you'd get "true" as the result.
That's because to test it appeared as
test ( string )
or redundant parentheses around a single operand test, which is (rather,
was) a test for the single operand not being a null string, and since "="
is not empty, the result was true.
And that's just with 3 args. Add more of them, without protecting
in some way every single one whose value you don't already know, and
you can end up in a world of pain. For simple things like string
equality/inequality tests, prepending a char, so the operand cannot be
anything starting with a '-' and also can't be '(' ')' or '!', is easy
(as in the "insert x" ... I always used to use "%${x}%" ... thought it
l
Re: interactive shell detection in shrc
First off let me thank you for your very detailed reply! As I wrote in my other message yesterday I've given up entirely on trying to test for interactivity without using $-. It just doesn't matter for any shell supporting $ENV since they all do the right thing with $-. I have discovered (by serendipity, having been reading the original Ash code to verify that it was setting $- with 'i' when necessary) that 's' is also set when the shell is reading from stdin, so for it testing for 's' in $-, and verifying stdin is a tty would also work to identify interactivity. Unfortunately that feature is not portable at all. The original Bourne shell actually puts 's' in $- even when given "-c command", and bosh continues this legacy. I don't know why it does this as it is entirely nonsensical. The original v7 manual doesn't document '-s'. From the code it looks like a bug: - options() notes and eats the '-c', and then returns the remaining number of arguments, which will be one. - main() turns on stdflg (the flag set by an explicit '-s' option argument) if options() returns less than 2, however since options() set comdiv to the '-c' parameter, it then sets things up to parse the string given and explicitly disables the input file descriptor (by setting it to -1). BTW, I see the original Bourne shell also tested stdin and _stdout_ when deciding if it was interactive or not. The change to test stderr must have come from AT&T Ksh. I see that's done as early as ksh88e, for example. At Thu, 10 Oct 2024 13:21:16 +0700, Robert Elz wrote: Subject: Re: interactive shell detection in shrc > > > jacaranda$ sh -c 'echo $0' > sh > > and if the user desires, $0 can be made anything > > jacaranda$ sh -c 'echo $0' anything > anything Ah ha! I had forgotten about how '-c' works with extra arguments! Even more fun the third argument can look like an option letter, but still just ends up in argv[0]: $ sh -c 'echo $0' -i -i This is different from how rsh and ssh work. They are just stuffing all arguments into a single string to pass to the moral equivalent of system(3) (but using the remote user's shell instead of explicitly /bin/sh). I recall this difference being extremely confusing and frustrating to me as a novice, but since I've exploited it often to help avoid quoting hell with formatting complex commands for remote execution. (I think I wanted 'rsh' just be an extension of 'sh's command-line API, for reasons I don't remember.) > might work, about 1 time in 50. And that's ignoring the very real > possibility that test (aka [) might one day just say "test: too many args" > as (ignoring the ']' arg when argv[0] == '[') you have 6 args there, and > test (these days) is only defined to work with a maximum of 4 (and even > with 4, only when the first is '!' - otherwise 3 or less). This part confuses me The manual suggests '-a', '-o', and parenthesis can be used to create expressions of arbitrary length and complexity, and surely I've done so for decades with multitudes of implementations with nary a problem. I agree POSIX does only require support for 4 arguments, but with the XSI extension any number are allowed, but I've never met a POSIX-minimal only implementation of test(1). -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpOSR5NFRIpp.pgp Description: OpenPGP Digital Signature
ls.1: incorrect -O flag description
The -O (not a POSIX one) flag seems incorrectly described in the manual page. What it does (from a cursory look at the sources, matching the result of testing), is simply not displaying a supplementary information about the directory traversed when going recursive. It does not output only leaf (filenames not directory). This is only the "headline": "\ndir:\n" that is not displayed. Just try: $ ls -OF for example (and combine with -R). What was the intention of the flag? To have an output with just the names (including directories) without the formatting about the newline and the dir? -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
