rm -rf ./ ../
Hello, the "rm" POSIX spec currently says: > If either of the files dot or dot-dot are specified as the > basename portion of an operand (that is, the final pathname > component) [...] rm shall write a diagnostic message to > standard error and do nothing more with such operands. AFAIK, that's to work around a bug/misfeature (IMO) in some shells, including POSIX compliant sh where the expansion of the ".*" glob includes "." and "..". That was fixed in the Forsyth shell and derivatives (pdksh and some derivatives at least), zsh and fish at least. "rm" seems to be the only command where that safeguard is applied. (find .*, ls -R .*, chmod -R 777 .*, chown -R nobody .* don't have such safeguards). Now what about: rm -rf ./ ../ AFAICT, with the above wording, that doesn't allow rm implementations to apply that safeguard in those cases (even though it's also a problem with rm -rf .*/). Solaris or FreeBSD rm seem to be compliant in that regard, but GNU and busybox rm at least complain: $ rm -rf ./ ../ rm: refusing to remove '.' or '..' directory: skipping './' rm: refusing to remove '.' or '..' directory: skipping '../' Would POSIX consider allowing (if not requiring) shell implementations to not include "." and ".." in their glob expansions to allow for those safer behaviour of zsh or pdksh? In my experience, having "." and ".." included is never desired and one has to go through too much/awkward-an effort to work around it like chmod -R go-rwx .[!.]* ..?* (see https://unix.stackexchange.com/questions/90073/does-rm-ever-delete-the-parent-directory/90075#90075 for some historical research into that). -- Stephane
Re: "-" operand to "sh"
2017-06-06 23:04:43 +0200, Jilles Tjoelker: [...] > > Yes, you're right, it looks like the "-" in: > > > sh +u-e > > > is just ignored (or everything is ignored for all I can tell > > with testing as there's nothing that can be turned off here). > > > More generally, given that there's no option enabled by default, > > it looks like "sh +anything" is pointless, which is why I said > > above "not sure why as it doesn't seem any option ever gets > > enabled by default, so there should be any need to turn them off > > on startup". Again, I suppose it's just because it shares the > > same code as "set". > > In interactive mode, job control (-m) is enabled automatically. Some > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow > starting an interactive shell without job control using sh +m, while > other shells, such as bash and ksh93, do not (the option is ignored). > > I use this feature in the FreeBSD sh testsuite to test interactive > features without needing to set up a tty. > > Disabling job control as the first command is not a suitable > alternative, since the harmful effects of a missing or improper tty > (warning messages and stop signals) occur before the first command. [...] True of POSIX shells, but that part of the discussion was about the Bourne shell where, in those versions where it was available, the -m option was not enabled by default. In POSIX shells, having sh +option can make sense for that -m indeed but also because those shells accept more than one option argument, so one can do: sh -x +x ... -- Stephane
Re: "-" operand to "sh"
On Tue, Jun 06, 2017 at 01:09:09PM +0100, Stephane CHAZELAS wrote: > 2017-06-06 13:46:33 +0200, Joerg Schilling: > > Stephane Chazelas wrote: > > > AFAICT the historical reason for "-" to also be the > > > end-of-option marker was that in the Bourne shell, options were > > > only considered in the first argument if it started with "-" > > > (and later, "+" as well). What follows the "-" is a list, > > > possibly empty of option letters (later sh +u-e was added > > > (though not sh -e+u), not sure why as it doesn't seem any option > > > ever gets enabled by default, so there should be any need to > > > turn them off on startup) > > I know of no shell that would suport any of those strings. > > The first letter decides whether it is an option, so '-' or '+' > > are permitted as the first letter. > > Any futher letter in the option string is handled as an option > > letter and '-' or '+' are not accepted. > [...] > Yes, you're right, it looks like the "-" in: > sh +u-e > is just ignored (or everything is ignored for all I can tell > with testing as there's nothing that can be turned off here). > More generally, given that there's no option enabled by default, > it looks like "sh +anything" is pointless, which is why I said > above "not sure why as it doesn't seem any option ever gets > enabled by default, so there should be any need to turn them off > on startup". Again, I suppose it's just because it shares the > same code as "set". In interactive mode, job control (-m) is enabled automatically. Some shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow starting an interactive shell without job control using sh +m, while other shells, such as bash and ksh93, do not (the option is ignored). I use this feature in the FreeBSD sh testsuite to test interactive features without needing to set up a tty. Disabling job control as the first command is not a suitable alternative, since the harmful effects of a missing or improper tty (warning messages and stop signals) occur before the first command. -- Jilles Tjoelker
Re: "-" operand to "sh"
2017-06-06 12:47:19 -0400, shwares...@aol.com: > I'm not against, as long as it doesn't reopen the trapdoor issue, but > think it would have to be explicit the option listing function, -o or +o > without > value, is not supported by sh, just set; including 'sh -o;' and 'sh +o;' > forms to keep it simple. This addresses the ambiguity that -o nonoptionvalue > is always an error then, not that nonoptionvalue might be construed as an > argument or command operand, or additional options. A command_file named > ./-o could be accessed as "sh - -o [options]... [--] [parameters]...;" then. Agreed. The sh synopsis indicates the option is required after -o, but the later reference to set for the description of the option makes it ambiguous. > A Usage note about using set with -c, e.g. > sh -c [other opts] "set -o; . script" script [argument]...; > to get the functionality for script debugging would provide guidance for > any scripts needing changes. Not sure it's needed. I don't think anyone ever used or would ever want to use sh -o myscript sh -o - myscript sh -o -- myscript sh -o -c 'some code' to mean print the list of options before running some code or myscript. -- Stephane
Re: "-" operand to "sh"
I'm not against, as long as it doesn't reopen the trapdoor issue, but think it would have to be explicit the option listing function, -o or +o without value, is not supported by sh, just set; including 'sh -o;' and 'sh +o;' forms to keep it simple. This addresses the ambiguity that -o nonoptionvalue is always an error then, not that nonoptionvalue might be construed as an argument or command operand, or additional options. A command_file named ./-o could be accessed as "sh - -o [options]... [--] [parameters]...;" then. A Usage note about using set with -c, e.g. sh -c [other opts] "set -o; . script" script [argument]...; to get the functionality for script debugging would provide guidance for any scripts needing changes. As XCU 2.5.3 specifies $ENV is to be processed after determining the shell is interactive, this indicates the options are to be processed previously in case these have -i specified. The implication I see is when the UP option is not supported shells shouldn't be processing $ENV at all, it looks, to keep things portable. Doing so would be extension behavior. I can see making it explicit that this processing occurs before processing command_file contents or command_string, as appropriate, to fix the expected order. In a message dated 6/6/2017 9:04:45 A.M. Eastern Daylight Time, stephane.chaze...@gmail.com writes: OK, going forward, to fix the spec, would we be in agreement that the spec should guarantee this: In: sh - Where can be any number argument starting with -, +, being "--", "-" or not. Those would be taken as operands (the first being the script name, the rest its arguments) sh -- being any combination of the options specified, being as above. Those would be taken as operands (whose interpretation depends on whether -c, -s are provided). For "-" to be treated as the first operand, it has to be preceded by a "--" end-of-option marker, or passed as "sh - -" Anything else is unspecified. In particular, sh -o - (or sh -o-) is unspecified, because "-" is not a valid option name (it doesn't matter whether some shells may choose to just ignore that "-" and/or treat it as disabling verbose and xtrace or report and error). sh -x - file is unspecified (behaviours vary in practice) same for sh -c - code (even if behaviours do not vary in practice in that instance). AFAICT, that would make the API usable (-- (and historical "sh -") can be relied upon), allow all current POSIX shell implementations, and not break "#! /bin/sh -" common usages. -- Stephane
Re: "-" operand to "sh"
2017-06-06 14:04:39 +0100, Stephane Chazelas: > OK, going forward, to fix the spec, would we be in agreement > that the spec should guarantee this: > > In: > > sh - > > Where can be any number argument starting with -, +, > being "--", "-" or not. > > Those would be taken as operands (the first being the > script name, the rest its arguments) [...] Clarifying: that may also be the empty list as in "sh -" is the same as "sh" alone (not particularly useful, but seems to work the same in all implementations). By the way, do we also need to say something about whether the options on the sh command lines are processed before or after the $ENV file is processed (for those that do as that's an optional feature). If $ENV is a file that contains "set +x", may running "sh -x" end up with "-x" still enabled? That would be quite unexpected (especially considering that whether $ENV is processed or not depends on the option parsing), but it might be worth stating explicitely. Something like: the content of the $ENV variable will be expanded and the content of the file at the resulting path will be interpreted after all options have been processed and before the first prompt is issued. -- Stephane
[1003.1(2016)/Issue7+TC2 0001142]: pread(2) and pwrite(2) should be async-signal-safe
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1142 == Reported By:dancol Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1142 Category: Base Definitions and Headers Type: Omission Severity: Editorial Priority: normal Status: New Name: Daniel Colascione Organization: User Reference: Section:2.4.3 Signal Actions Page Number: Line Number: Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-03 23:42 UTC Last Modified: 2017-06-06 13:48 UTC == Summary:pread(2) and pwrite(2) should be async-signal-safe == -- (0003754) geoffclare (manager) - 2017-06-06 13:48 http://austingroupbugs.net/view.php?id=1142#c3754 -- The standard already requires pread() and pwrite() to be async-signal-safe. The fact that they are missing from the list in 2.4.3 is simply an editorial omission (and Daniel correctly classified this bug as such). This is because the description of pread() says "The pread() function shall be equivalent to read(), except that it shall read from a given position in the file without changing the file offset." In order for pread() not to be required to be async-signal-safe, the standard would instead have to say "The pread() function shall be equivalent to read(), except that it shall read from a given position in the file without changing the file offset and it need not be async-signal-safe." Likewise for pwrite(). Issue History Date ModifiedUsername FieldChange == 2017-06-03 23:42 dancol New Issue 2017-06-03 23:42 dancol Name => Daniel Colascione 2017-06-03 23:42 dancol Section => 2.4.3 Signal Actions 2017-06-06 12:14 shware_systems Note Added: 0003753 2017-06-06 13:48 geoffclare Note Added: 0003754 ==
Re: "-" operand to "sh"
OK, going forward, to fix the spec, would we be in agreement that the spec should guarantee this: In: sh - Where can be any number argument starting with -, +, being "--", "-" or not. Those would be taken as operands (the first being the script name, the rest its arguments) sh -- being any combination of the options specified, being as above. Those would be taken as operands (whose interpretation depends on whether -c, -s are provided). For "-" to be treated as the first operand, it has to be preceded by a "--" end-of-option marker, or passed as "sh - -" Anything else is unspecified. In particular, sh -o - (or sh -o-) is unspecified, because "-" is not a valid option name (it doesn't matter whether some shells may choose to just ignore that "-" and/or treat it as disabling verbose and xtrace or report and error). sh -x - file is unspecified (behaviours vary in practice) same for sh -c - code (even if behaviours do not vary in practice in that instance). AFAICT, that would make the API usable (-- (and historical "sh -") can be relied upon), allow all current POSIX shell implementations, and not break "#! /bin/sh -" common usages. -- Stephane
Re: [1003.1(2016)/Issue7+TC2 0001142]: pread(2) and pwrite(2) should be async-signal-safe
>-- > (0003753) shware_systems (reporter) - 2017-06-06 12:14 > http://austingroupbugs.net/view.php?id=1142#c3753 >-- >While this looks reasonable, the restriction on pread() and pwrite() of not >disturbing the seek position is problematic. It means an effective >dup();lseek();read() or write();close() sequence occurs on each invoke. This doesn't make sense: dup() creates a file pointer with: osame file pointer (that is, both file descriptors share one file pointer) lseek() on a dup()'ed file will move the lseek on the original file pointer as well. (That makes it possible to write an "lseek(1)" utility which can be used to change the file pointer for inherited file descriptors) Casper
Re: "-" operand to "sh"
If the text wasn't explicit it was to be considered an operand that gets eaten, not a switch option value, I'd agree that's how "sh -o -" should be construed; the '-' would be an illegal option value. Because it is required to be eaten, this leaves -o without a following value at all in the operand list so I believe the two forms are supposed to be equivalent in effect as the intent. If anything is suspect as a possible extension it is using unquoted -- to indicate no command_name operand in my longer example. Some might expect $0 to be set to '--' instead of 'verbose' or be unchanged from 'sh'. I prefer to think of it as permitted as a delimiter of when positional parameter assignments begin. The rationale goes into that shells that didn't construe '-' as stated were being required to change, so all scripts can address the -i trapdoor issue. The standard chose between conflicting interpretations, not indulged in invention. It would be nice, but not necessary, if the version chosen as reference implementation for that interpretation was stated there. If some shells, no matter how ubiquitous, still don't they are buggy. Full stop. Those shells Do not pass Go since Issue 2. It is not a standard defect. It is probably a missing corner case of the test suite, however. As the issue only affects some implementations, I consider the ambiguity of -o having different effects when it has an option value and none why some shells had it to begin with, as the primary reason, and it's more a happy accident it addresses the trapdoor issue too. This ambiguity exists since set does not follow Utility Convention XBD 12.1, #2b. in how -o is specified, as can be argued it should. Even then you still need '-' defined like this for sh, due to use of '+' as additional switch prefix which might begin a utility name, so I'm not going to quibble over this. It's a historical oddity. ksh giving '-' a different function is possibly a bug in it, and this is a place where the standard deliberately does not use how it did things as the reference, as the Rationale also goes into. That function is ok for set because it doesn't have to consider any operand as a command file, string or name, they're all positional parameter replacements; but it is not ok if it happens when ksh is invoked as sh, that I see. In a message dated 6/3/2017 3:39:28 P.M. Eastern Daylight Time, stephane.chaze...@gmail.com writes: 2017-06-03 10:53:58 -0400, shwares...@aol.com: > I believe the purpose of this relates to when the -o option is specified > it provides a way to use the no operand form to list values set from the > environment at startup, so sh -o - ; or sh -o ; behaves like set -o ; but > still permits something like > sh -co - verbose -- arg1 ; [...] I don't think it's that as, in "sh -o -", the - would be an argument to "-o" (and unspecified as "-" is not one of the POSIX option names). I think I have an idea where the first part of the text in the spec may come from though. And thanks for bringing up "-o" as that's testing with those that made be realise it. In ksh, as I just found out set - resets the xtrace and verbose options and marks the end of option. That part is documented. That's probably for compatibility with the Bourne shell as Solaris 10's /bin/sh seems to do it (not documented though) ksh - Also resets the xtrace and verbose options (as that shares the same code). It's somehow documented via the reference to "set" in the invocation description. It also marks the end of options.
[1003.1(2016)/Issue7+TC2 0001142]: pread(2) and pwrite(2) should be async-signal-safe
A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1142 == Reported By:dancol Assigned To: == Project:1003.1(2016)/Issue7+TC2 Issue ID: 1142 Category: Base Definitions and Headers Type: Omission Severity: Editorial Priority: normal Status: New Name: Daniel Colascione Organization: User Reference: Section:2.4.3 Signal Actions Page Number: Line Number: Interp Status: --- Final Accepted Text: == Date Submitted: 2017-06-03 23:42 UTC Last Modified: 2017-06-06 12:14 UTC == Summary:pread(2) and pwrite(2) should be async-signal-safe == -- (0003753) shware_systems (reporter) - 2017-06-06 12:14 http://austingroupbugs.net/view.php?id=1142#c3753 -- While this looks reasonable, the restriction on pread() and pwrite() of not disturbing the seek position is problematic. It means an effective dup();lseek();read() or write();close() sequence occurs on each invoke. While each of these operations is supposed to be asynch-safe, how they're combined, or implemented otherwise internally, may not be; so requiring this could break existing implementations. If the routines use malloc() to get space for temporary descriptors or buffers, as example, this would make the entire routine unsafe, since malloc() is also not in the safe list. Issue History Date ModifiedUsername FieldChange == 2017-06-03 23:42 dancol New Issue 2017-06-03 23:42 dancol Name => Daniel Colascione 2017-06-03 23:42 dancol Section => 2.4.3 Signal Actions 2017-06-06 12:14 shware_systems Note Added: 0003753 ==
Re: "-" operand to "sh"
2017-06-06 13:46:33 +0200, Joerg Schilling: > Stephane Chazelas wrote: > > > AFAICT the historical reason for "-" to also be the > > end-of-option marker was that in the Bourne shell, options were > > only considered in the first argument if it started with "-" > > (and later, "+" as well). What follows the "-" is a list, > > possibly empty of option letters (later sh +u-e was added > > (though not sh -e+u), not sure why as it doesn't seem any option > > ever gets enabled by default, so there should be any need to > > turn them off on startup) > > I know of no shell that would suport any of those strings. > > The first letter decides whether it is an option, so '-' or '+' > are permitted as the first letter. > > Any futher letter in the option string is handled as an option > letter and '-' or '+' are not accepted. [...] Yes, you're right, it looks like the "-" in: sh +u-e is just ignored (or everything is ignored for all I can tell with testing as there's nothing that can be turned off here). More generally, given that there's no option enabled by default, it looks like "sh +anything" is pointless, which is why I said above "not sure why as it doesn't seem any option ever gets enabled by default, so there should be any need to turn them off on startup". Again, I suppose it's just because it shares the same code as "set". -- Stephane
Re: "-" operand to "sh"
Stephane CHAZELAS wrote: > I don't think it's that as, in "sh -o -", the - would be an > argument to "-o" (and unspecified as "-" is not one of the POSIX > option names). ksh93 and bosh start an interractive shell that first does "set -o" > I think I have an idea where the first part of the text in the > spec may come from though. And thanks for bringing up "-o" as > that's testing with those that made be realise it. > > In ksh, as I just found out > > set - > > resets the xtrace and verbose options and marks the end of > option. That part is documented. That's probably for > compatibility with the Bourne shell as Solaris 10's /bin/sh > seems to do it (not documented though) This is documented for the Bourne Shell already. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: "-" operand to "sh"
Stephane Chazelas wrote: > AFAICT the historical reason for "-" to also be the > end-of-option marker was that in the Bourne shell, options were > only considered in the first argument if it started with "-" > (and later, "+" as well). What follows the "-" is a list, > possibly empty of option letters (later sh +u-e was added > (though not sh -e+u), not sure why as it doesn't seem any option > ever gets enabled by default, so there should be any need to > turn them off on startup) I know of no shell that would suport any of those strings. The first letter decides whether it is an option, so '-' or '+' are permitted as the first letter. Any futher letter in the option string is handled as an option letter and '-' or '+' are not accepted. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
