race condition in mv -i (Was: race condition with set -C)

2016-11-07 Thread Stephane Chazelas
2016-11-07 17:19:13 +, Geoff Clare: [...] > > Is that allowed by POSIX? > > No; the standard clearly says "The mv utility shall perform actions > equivalent to the rename() function" in step 3. Well, when moving across file systems, it already does something very different from an atomic

Re: links broken in HTML basedef toc

2016-11-09 Thread Stephane Chazelas
2016-11-09 11:35:37 +, Andrew Josey: [...] > This does flag a question to me about whether adding new terms > goes beyond the true scope of a TC ( one to discuss another > time) [...] Note that it's not only those terms. Some whole sections have been added. Compare

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 Thread Stephane Chazelas
2016-11-02 13:32:44 +, Martijn Dekker: [...] > If both 'mkdir' and 'ln' operate atomically, there could be a safe > workaround for creating a regular file directly under /tmp. It would > involve creating a (very) temporary directory under /tmp using 'mkdir > -m700', then creating the file

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 Thread Stephane Chazelas
2016-11-07 15:57:25 +, Stephane Chazelas: > 2016-11-07 15:40:15 +, Geoff Clare: > [...] > > > Same problem with "mv" (which I think would work just > > > as well (with LC_ALL=C mv -i < /dev/null 2> /dev/null)) > > > > No, mv -i

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 Thread Stephane Chazelas
2016-11-07 16:20:08 +, Geoff Clare: [...] > > How so? "mv -i" with /dev/null as stdin ("no" answer to prompt) > > is not supposed to remove anything. > > Only if it prompts. If the existence check fails, mv will not > prompt and will just call rename(). OK, sorry, I had assumed rename()

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 Thread Stephane Chazelas
2016-11-07 16:10:01 +, Stephane Chazelas: [...] >mv -i a b < /dev/null 2>&- > > seem to work with GNU or Solaris10 mv (in that it returns with > an error when a prompt fails to be issued) but not with > FreeBSD's [...] Sorry, I messed up my tests on Solaris. Sola

Re: [1003.1(2013)/Issue7+TC1 0001016]: race condition with set -C

2016-11-07 Thread Stephane Chazelas
2016-11-07 16:57:34 +, Stephane Chazelas: [...] > OK, sorry, I had assumed rename() would fail if the target exits > already. [...] BTW, in the spec of link(2): [EEXIST] The path2 argument resolves to an existing directory entry or

Re: Should aliases expand after 'command'?

2016-10-25 Thread Stephane Chazelas
2016-10-23 20:39:01 -0400, David Korn: > In ksh-88 on which the standard was based, the man page says that if an > alias ends in a space then the next word is checked for an alias. This > seems to be omitted in the posix standard without any comment in the > rationale as to why. > > Anyway in

Solaris 11 certification and broken links at www.opengroup.org

2017-04-21 Thread Stephane Chazelas
Hello, today I found out that Solaris 11 didn't have the POSIX utilities installed by default unless you did a full desktop or server install (or installed the xcu4/xcu6 relevevant packages by hand) https://unix.stackexchange.com/questions/360359/posix-awk-on-solaris-11 Solaris 11 being SUSv3

Re: Solaris 11 certification and broken links at www.opengroup.org

2017-04-21 Thread Stephane Chazelas
2017-04-21 15:22:53 +0100, Andrew Josey: [...] > This means that Oracle commits to keep Solaris 11 and its > maintenance releases in compliance, and that if a buyer orders > a compliant system it will be delivered in the correct > configuration. OK, "Solaris 11 and its maintenance releases" make

Re: I/O semantics of pipe and FIFO.

2017-03-04 Thread Stephane Chazelas
2017-03-04 13:14:08 +, Danny Niu: > Hi all. > > I couldn't remember where I saw it saying, that when reading > from a pipe or a FIFO, the read syscall returns the content of > at most one write call. It's a bit similar to the > message-nondiscard semantics of dear old STREAM. > >

shell redirection to globs

2017-07-31 Thread Stephane Chazelas
The spec (http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/V3_chap02.html#tag_18_07) says: > the word that follows the redirection operator shall be > subjected to tilde expansion, parameter expansion, command > substitution, arithmetic expansion, and quote removal. Pathname

sh -c '{ exec > a; } > b; echo x' > c

2017-08-12 Thread Stephane Chazelas
Hello, where shall "x\n" be output when one does: sh -c '{ exec > a; } > b; echo x' > c or: sh -c 'eval "exec > a" > b; echo x' > c ? As "exec" should apply the redirection to the current execution environment, stdout should be redirected to "a", but redirecting the {...;} compound command

Re: sh -c '{ exec > a; } > b; echo x' > c

2017-08-14 Thread Stephane Chazelas
2017-08-14 10:03:52 +0100, Geoff Clare: [...] > > All shells I tried output to "c" there, which to a user can be > > confusing. Maybe the mechanism should be specified somehow in > > the spec, like a note in the description of the "exec" utility. > > Not sure of the best way to express it though.

Re: Should "exec" run a shell function?

2017-07-18 Thread Stephane Chazelas
On 18 July 2017 15:59:08 BST, Robert Elz > | I wonder if it is worth noting that you can also use 'env printf' > | instead of '(exec printf)' to get the same PATH lookup properties of > | bypassing a shell builtin. > >I wouldn't, because I do not believe that is correct.

Re: Should "exec" run a shell function?

2017-07-21 Thread Stephane Chazelas
2017-07-16 20:47:52 +0200, Martijn Dekker: > A test script: > > #! /bin/sh > true() { > echo "exec runs function" > } > exec true > > On zsh, pdksh and mksh, 'exec' runs the shell function. On all other > POSIX shells (at least bash, dash, yash, ksh93, FreeBSD sh), it runs the > external

Re: Should "exec" run a shell function?

2017-07-19 Thread Stephane Chazelas
On 19 July 2017 00:38:06 BST, Robert Elz wrote: >Personally I think "env" should be restricted in usage to "run a >utility after >manipulating the environment" and not have any other semantics applied >to it. In effect, env is the cli to the execve system call. > > | exec

Re: Should "exec" run a shell function?

2017-07-21 Thread Stephane CHAZELAS
2017-07-21 10:52:06 +0200, Joerg Schilling: > > busybox does have a which command, but like most which commands, > > it has a few bugs/misfeatures (in the case of busybox is seems > > it mishandles empty $PATH components). In most common cases, one > > Be careful, "which" is a csh script and the

Re: Solaris 11 certification and broken links at www.opengroup.org

2017-04-24 Thread Stephane CHAZELAS
2017-04-24 11:42:12 +0200, Joerg Schilling: [...] > Alan Coopersmith wrote: > > > That is incorrect. The "update XXX" naming has always been internal to > > Solaris. > > Solaris 10 and prior releases used the date for the marketing name > > ("Solaris 7 > > 8/99",

Re: $ "1st" or $ unset_var (and $(1/2*2)) in awk

2017-08-22 Thread Stephane Chazelas
2017-08-22 15:21:11 +0100, Stephane Chazelas: > Hello, > > The awk specification currently says: > > SUSv4TC2> Field variables shall be designated by a '$' followed by a > SUSv4TC2> number or numerical expression.

Re: Re bug 528 (sed -E) terminology: EREs have no back-references

2017-05-03 Thread Stephane Chazelas
2017-05-03 12:21:58 -0400, Wayne Pollock: > Isn't there a related bug to add back references to > ERE's? [...] That would be a welcome addition indeed. One issue with backreferences in EREs is that in awk awk '/(.)\1/' is already meant to match a character followed by a character of code 0x1.

Re: locale-dependent shell parsing (was: sh(1): is roundtripping of the positional parameter stack possible?)

2017-05-17 Thread Stephane Chazelas
2017-05-17 10:21:13 +0100, Stephane Chazelas: [...] > bash has a similar issue. It treats [:blank:] as delimiters > only in locales with single-byte charsets. See > https://lists.gnu.org/archive/html/bug-bash/2014-10/msg00098.html > and the whole discussion there. [...] http

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-17 Thread Stephane Chazelas
2017-05-17 14:12:28 +0700, Robert Elz: [...] > | Depends. If quoting only a handful a arguments, then that call > | to awk might cost you you a couple of milliseconds indeed. But > | if processing thousands, you might find that it saves a few > | seconds. > > And if I really had an

Re: locale-dependent shell parsing (was: sh(1): is roundtripping of the positional parameter stack possible?)

2017-05-17 Thread Stephane Chazelas
2017-05-17 09:37:31 +0100, Geoff Clare: [...] > That would appear to be a bug in the standard, as it doesn't match > existing practice in any of the shells I tried (with a UTF-8 locale): > > $ printf 'echo\u00a0foo\n' | grep '[[:blank:]]' > echo foo > $ printf 'echo\u00a0foo\n' | sh

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-16 Thread Stephane Chazelas
2017-05-16 17:33:26 +0700, Robert Elz: [...] > | Or just write it as quote() (...) instead of quote() { ...;} > > Yes, as you would have seen later, I mentioned that in a subsequent > message. Sorry about that. I hadn't seen that message at the time I replied. [...] > | Here, I'd fire awk

[OT] of the merit of using awk for performance or who's got the fastest quote() (Was: sh(1): is roundtripping of the positional parameter stack possible?)

2017-05-16 Thread Stephane Chazelas
2017-05-16 17:29:13 +0100, Stephane Chazelas: [...] > > | Here, I'd fire awk and quote more than one arg at a time: > > > > Hmm - you're really aiming for maximum sluggishness... I could beat that > > by just adding a couple of sleeps ... > > Depends. If quot

Re: locale-dependent shell parsing (was: sh(1): is roundtripping of the positional parameter stack possible?)

2017-05-17 Thread Stephane Chazelas
2017-05-17 14:00:21 +0200, Steffen Nurpmeso: [...] > |BTW, U+00A0, should really not be a [:blank:] or [:space:]. > |That's the whole point of that "non-breaking space" character. > > It is clearly defined as whitespace in Unicode and thus ISO, at > least once i last worked with the Unicode

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-17 Thread Stephane Chazelas
2017-05-17 13:49:18 +0200, Steffen Nurpmeso: [...] > vpospar set x 'a \ b' "foo'" "\\'b\\a\\r\\" Aä > echo "$#: <${1}><${2}><${3}><$4><$5>" > vput vpospar x quote; eval vpospar set ${x} > echo $#: <${1}><${2}><${3}><$4><$5> [...] Your problem here is with your usage of echo. You can't use

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-17 Thread Stephane Chazelas
2017-05-17 14:41:31 +0100, Geoff Clare: [...] > Regarding the expansion of $1'' I think the standard is clear that > if $1 ends with a non-whitespace IFS character, Jilles is right and > there will be a final empty field. This is because quote removal > is done after field splitting. For example

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-17 Thread Stephane Chazelas
2017-05-17 15:07:26 +0100, Stephane Chazelas: [...] > OK, so that would confirm it's a conformance bug in ksh88. ksh93 > would probably have another one in: > > ~$ a=a::b: ksh93 -c 'IFS=:; printf "<%s>\n" $a""' > > <> > > &

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-16 Thread Stephane Chazelas
2017-05-16 10:03:56 +0700, Robert Elz: > Date:Mon, 15 May 2017 18:36:58 +0200 > From:Steffen Nurpmeso > Message-ID: <20170515163658.b7ljs%stef...@sdaoden.eu> [...] > Alternatively, you could implement this as an external #! script, that > would be

Re: sh(1): is roundtripping of the positional parameter stack possible? (Was: Re: Shell parameter expansions involving '#")

2017-05-16 Thread Stephane Chazelas
2017-05-16 10:03:56 +0700, Robert Elz: [...] > $ y=$(quote "$x") [...] > Just remember to always quote variable references "$x" unless you are > 100% certain what the content of the variable is, eg: as above with $y > where we know it is the result of the quote function, so is safe. [...] No,

Re: rm -rf ./ ../

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 11:10:36 +0200, Joerg Schilling: > Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote: > > > Could it be that it means that "." and ".." should be returned > > *first* when they're there on XSI systems? (which would be yet > > ano

Re: rm -rf ./ ../

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 03:37:30 +0700, Robert Elz: > Date:Wed, 7 Jun 2017 20:56:17 +0100 > From: Stephane CHAZELAS <stephane.chaze...@gmail.com> > Message-ID: <20170607195617.gf5...@chaz.gmail.com> > > | I imagine that text was there for some reason.

Re: "-" operand to "sh"

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 11:39:31 +0200, Joerg Schilling: > Jilles Tjoelker wrote: > > > > While doing this, I discovered that the Burne Shell first parses the > > > command line options and later decides whether the current shell is > > > interactive. For this reason, I do not see that it

Re: readdir and d_ino of mount points (Was: rm -rf ./ ../)

2017-06-12 Thread Stephane Chazelas
2017-06-12 09:58:30 +0100, Geoff Clare: [...] > > - In the second case (the one in FreeBSD, Linux and Solaris at > > least), that's the inode number of a file we > > cannot access by that path (and again, applications using > > d_inos to detect hard links could be fooled). [...] > You say

Re: Access to old POSIX specifications (Was: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html)

2017-06-09 Thread Stephane Chazelas
2017-06-08 22:15:57 +, Joe Gwinn: [...] > What will you do with this old standard? [...] In my case, it's only for personal interest, archaeological purposes, to answer questions like: - when was that added to which standard? - is feature X a POSIX invention? - was feature Y in

Re: compound-list

2017-06-12 Thread Stephane Chazelas
2017-06-12 20:05:49 +, Yann Régis-Gianas: > Dear members of the Opengroup, > > the shell grammar is defining the non terminal for compound_list as follows: > > compound_list : linebreak term | linebreak term separator ; > > and this non terminal is used in compound_commands like

Why f() compound-command only? (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
2017-05-23 23:38:40 +, Austin Group Bug Tracker: [...] > My guess (pure guess) would be that it was not specified to allow > "command" > but only "compound-command", as allowing "command" that way makes a > redirect > at the end of the line ambiguous - just what does that mean, ie: in > > f()

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
2017-05-24 17:00:25 +0200, Joerg Schilling: [...] > > Let's be serious, if "posh" had such a bug it would have been > > reported long ago and fixed. Presumably, you've compiled > > it in a such way or on such a system that has never been tested > > before and triggered a bug. > > A shell that

Re: incorrect example for "export"

2017-05-24 Thread Stephane Chazelas
2017-05-24 15:06:59 +0200, Vincent Lefevre: > It seems that the example for "export" is incorrect: > >Save and restore all exported variables: > >export −p > temp-file >unset a lot of variables >... processing >. temp-file > [...] One may

What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane Chazelas
2017-05-24 13:02:56 +, Austin Group Bug Tracker: [...] > (0003745) joerg (reporter) - 2017-05-24 13:02 > http://austingroupbugs.net/view.php?id=767#c3745 > -- > It seems that we should set up a list of shell

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane Chazelas
2017-05-24 14:48:12 +0100, Stephane Chazelas: [...] > > bash > > bosh > > As discussed, as of the 2017-05-16 release, posh was not POSIX > and still had many of non-conformances of the Bourne shell. [...] Sorry, I meant "bosh", not "posh" above. The

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
2017-05-24 16:15:03 +0200, Joerg Schilling: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > > > If your "configure" script works with "mksh" but not with > > "posh", I suspect it's because that script is using non-POSIX > >

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
2017-05-24 16:21:05 +0200, Joerg Schilling: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > > > 2017-05-24 14:48:12 +0100, Stephane Chazelas: > > [...] > > > > bash > > > > bosh > > > > > > As discussed, as of the 2017

should unset clear the "export" attribute (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
2017-05-24 12:59:59 +, Austin Group Bug Tracker: [...] > (0003744) kre (reporter) - 2017-05-24 12:59 > http://austingroupbugs.net/view.php?id=767#c3744 > -- > We can always avoid the unset var/func ambiguity by always >

behaviour when for modified env vars (Was: What shell implementations to consider)

2017-05-24 Thread Stephane CHAZELAS
2017-05-24 17:15:25 +0200, Joerg Schilling: > Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote: [...] > > $ a=1 ./sh -o posix -c 'a=2; printenv a' > > 1 > > > > POSIX requires 2 to be output there (assuming printenv a command > > to print the value of

Re: What shell implementations to consider (Was: [1003.1(2008)/Issue 7 0000767]: Add built-in "local")

2017-05-24 Thread Stephane CHAZELAS
2017-05-24 17:21:33 +0200, Joerg Schilling: > Joerg Schilling wrote: > > > I did not change the Bourne Shell behavior as I believe that the > > export behavior is compatibile with POSIX and as this behavior is more > > useful > > than what other shells do.

Re: [1003.1(2013)/Issue7+TC1 0001045]: Issues with "cd -"

2017-05-26 Thread Stephane Chazelas
2017-05-25 16:33:40 +, Austin Group Bug Tracker: [...] > (0003749) geoffclare (manager) - 2017-05-25 16:33 > http://austingroupbugs.net/view.php?id=1045#c3749 > -- > Interpretation response Thanks Geoff for that. [...] >

About string quoting extended operators (Was: [OT] of the merit of using awk for performance or who's got the fastest quote())

2017-05-19 Thread Stephane Chazelas
2017-05-19 20:41:12 +, Thorsten Glaser: > Stephane Chazelas dixit: > > >In mksh, printf is not built-in which doesn't help. In all but > > But in mksh, you just do this to quote: > > local foo > set -A foo > for x in "$@"; do > foo+

Re: "-" operand to "sh"

2017-06-02 Thread Stephane Chazelas
2017-06-02 16:33:03 +0100, Geoff Clare: [...] > I'm fairly sure the intention is that only: > > sh [options]... -- - [operands]... > > is undefined, but it's been badly worded and thus also applies to other > cases that it obviously wasn't meant to cover. [...] Thanks. But even then, what would

Re: "-" operand to "sh"

2017-06-02 Thread Stephane Chazelas
2017-06-02 17:18:27 +0100, Geoff Clare: [...] > > or mean stdin (in which case I'd expect "sh - -" to also be a > > problem)? I can't find any. > > I don't think treating '-' as stdin would have been a consideration, > but we need to keep that in mind when we come up with new wording, so > as not

Re: "-" operand to "sh"

2017-06-03 Thread Stephane CHAZELAS
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

Re: "-" operand to "sh"

2017-06-03 Thread Stephane CHAZELAS
2017-06-03 20:39:24 +0100, Stephane CHAZELAS: [...] > 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

Re: "-" operand to "sh"

2017-06-03 Thread Stephane CHAZELAS
2017-06-04 04:49:29 +0700, Robert Elz: [...] >| which btw means that things like "#! /bin/sh -ue" are no longer safe > > Does anyone really ever do that, rather than > > #! /bin/sh > set -ue Well #! /bin/sh - set -ue If the point was to be "safe"/"pedantic" and allow the

Re: "-" operand to "sh"

2017-06-04 Thread Stephane CHAZELAS
2017-06-04 08:45:33 +0700, Robert Elz: [...] > | The awk (or sed) case is more broken though. > | Your awk script can't take options or at least not options also > > It was never intended to be a panacea - just a convenience to allow > simple scripts (whose name is known, after all, the

Re: rm -rf ./ ../

2017-06-07 Thread Stephane CHAZELAS
2017-06-07 10:58:58 -0400, shwares...@aol.com: > Applications can be written portably and are expected to take into account > a generic file operand is '.' or '..' already; readdir() may or may > not include '.' or '..' values whenever a path crosses a device mount > boundary. It may only

Re: rm -rf ./ ../

2017-06-07 Thread Stephane Chazelas
2017-06-07 09:03:52 +0100, Geoff Clare: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 06 Jun 2017: [...] > > rm -rf ./ ../ > > > > AFAICT, with the above wording, that doesn't allow rm > > implementations to apply that safeguard in those cases (ev

Re: rm -rf ./ ../

2017-06-07 Thread Stephane CHAZELAS
2017-06-07 12:41:31 -0400, shwares...@aol.com: > Because of the 'dot or dot-dot', not 'dot and dot-dot', I construe 'they' > as "one or the other, or both if both missing" shall not be returned. You > don't synthesize an unnamed or assigned name record for one that isn't > present, to relate

Re: rm -rf ./ ../

2017-06-07 Thread Stephane CHAZELAS
2017-06-07 12:41:52 +0200, Joerg Schilling: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > > > Do you have an opinion on whether POSIX should allow the > > expansion of globs not to include "." and ".." by default?

Re: rm -rf ./ ../

2017-06-07 Thread Stephane Chazelas
2017-06-07 12:24:33 +0100, Geoff Clare: [...] > > Yes, it's hard to tell what behaviour one can rely on with the > > current text. Is opendir(".") required to open the current > > directory even if there's no "." entry in the current directory > > (same for "..")? Is foo/./bar required to be the

s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Stephane Chazelas
Hello, I just came across https://www.opengroup.org/austin/papers/posix_faq.html where question Q0, Q3 ("What is the latest version of POSIX.1?") would need to be updated following the recent release of TC2. -- Stephane

Re: s/2013/2016/g at https://www.opengroup.org/austin/papers/posix_faq.html

2017-06-08 Thread Stephane Chazelas
2017-06-08 13:02:45 +0100, Stephane Chazelas: [...] > I just came across > https://www.opengroup.org/austin/papers/posix_faq.html > where question Q0, Q3 ("What is the latest version of POSIX.1?") > would need to be updated following the recent release of TC2. [...] Q18 as

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 12:11:22 +0100, Geoff Clare: [...] > I can't answer that without knowing why the Base Working Group decided > to put in that text instead of using the POSIX.1-1990 text. It's > possible there might be some defect report against a draft of XSH4, or > a discussion in the email archives

About Q15 in the POSIX FAQ

2017-06-08 Thread Stephane Chazelas
https://www.opengroup.org/austin/papers/posix_faq.html > Q15. Does removal of obsolescent utility syntax mean that > implementations supporting usages of head -5 file, tail -5 file, > tail -l file are no longer allowed? > > No, in general the intent of removing the obsolescent forms of > the

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 11:01:29 +0100, Geoff Clare: > Robert Elz wrote, on 08 Jun 2017: > > > > And while here, I am also not in favour of attempts to "fix" breakage, just > > so we appear to conform to the standard. If "." and ".." are supposed to > > appear in the directories, and (for

Re: rm -rf ./ ../

2017-06-08 Thread Stephane Chazelas
2017-06-08 12:11:22 +0100, Geoff Clare: [...] > > OK, but the question remains: "what does it mean?". A "stricter > > requirement" for what? That "." or ".." should not come without > > the other (my interpretation)? Or that they should not be > > treated specially (Mark's interpretation) or that

Re: rm -rf ./ ../

2017-06-08 Thread Stephane CHAZELAS
2017-06-08 22:34:30 +0700, Robert Elz: > Date:Thu, 8 Jun 2017 10:50:07 +0100 > From: Stephane CHAZELAS <stephane.chaze...@gmail.com> > Message-ID: <20170608095007.gb7...@chaz.gmail.com> > > | It would be like saying: find . -

Re: "-" operand to "sh"

2017-06-06 Thread Stephane Chazelas
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 "--", "-"

Re: "-" operand to "sh"

2017-06-06 Thread 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) sh --

Re: "-" operand to "sh"

2017-06-06 Thread Stephane CHAZELAS
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

rm -rf ./ ../

2017-06-06 Thread Stephane Chazelas
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

Re: rm -rf ./ ../

2017-06-09 Thread Stephane Chazelas
2017-06-08 15:19:01 +0100, Geoff Clare: [...] > In any case, the problem statement is only the submitter's > interpretation. The fact that the bug was accepted does not mean > the group agreed with the problem statement, only with the > suggested change. [...] Yes, sorry, I did not mean to imply

readdir and d_ino of mount points (Was: rm -rf ./ ../)

2017-06-09 Thread Stephane Chazelas
2017-06-09 15:46:56 +0100, Stephane Chazelas: [...] > In addition to leaving it unspecified whether a "." or ".." > entry is returned, we may also want to clarify (or leave > unspecified) what d_ino the ".." entry may have for mount-points > and that in an

Re: compound-list

2017-06-15 Thread Stephane CHAZELAS
2017-06-15 13:56:16 +0200, Joerg Schilling: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > > > One more major issue identified in this thread is that in TC2, > > the "until" in > > > > < file until... > > > > or: >

Re: compound-list

2017-06-15 Thread Stephane Chazelas
2017-06-15 16:58:18 +0700, Robert Elz: > Date:Thu, 15 Jun 2017 08:12:37 + > From:=?UTF-8?B?WWFubiBSw6lnaXMtR2lhbmFz?= > > Message-ID: > > > | If my

order of assignments (Was: [1003.1(2016)/Issue7+TC2 0001150]: exit status of command substitution not properly specified)

2017-06-16 Thread Stephane CHAZELAS
2017-06-16 16:19:27 +, Austin Group Bug Tracker: [...] > In > a=a; a=x b=$a > it is explicitly unspecified whether b=a or b=x at > the conclusion. It would be astounding if there was > to be a stricter requirement for $? [...] Is it really? I do remember it was discussed some time

Re: order of assignments (Was: [1003.1(2016)/Issue7+TC2 0001150]: exit status of command substitution not properly specified)

2017-06-16 Thread Stephane CHAZELAS
2017-06-16 18:38:42 +0200, Joerg Schilling: [...] > > I do remember it was discussed some time ago and the outcome was > > that $b should be x. It was reported to "dash" (as a POSIX > > conformance bug) and despite initial reticence, dash was changed > > so as to perform assignments left to right

Re: compound-list

2017-06-13 Thread Stephane Chazelas
2017-06-13 07:22:10 +0100, Stephane Chazelas: > 2017-06-13 00:02:34 +0200, Jilles Tjoelker: > [...] > > I think this is supposed to be handled by rule 1 in the first (non-yacc) > > part of 2.10.2 Shell Grammar Rules, but the text is not clear to me. For > > example, rule

Re: compound-list

2017-06-13 Thread Stephane Chazelas
2017-06-13 00:02:34 +0200, Jilles Tjoelker: [...] > I think this is supposed to be handled by rule 1 in the first (non-yacc) > part of 2.10.2 Shell Grammar Rules, but the text is not clear to me. For > example, rule 7b for non-initial words in a simple command says rule 1 > should be applied, but

Re: "-" operand to "sh"

2017-06-06 Thread Stephane CHAZELAS
2017-06-06 13:46:33 +0200, Joerg Schilling: > Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > > > AFAICT the historical reason for "-" to also be the > > end-of-option marker was that in the Bourne shell, options were > > only consid

Re: ksh93 compliance [was: FYI: ksh88 (/usr/xpg4/bin/sh) ...]

2017-10-06 Thread Stephane CHAZELAS
2017-10-06 17:28:21 +0200, Martijn Dekker: [...] > Ah yes, I had forgotten about that. In fact, ksh93 does not have a > 'times' builtin at all -- it defaults to an alias: > > $ type times > times is an alias for '{ { time;} 2>&1;}' [...] Which causes some compliance issues like:

Re: Should 'exec' export assignments to external commands?

2017-09-09 Thread Stephane Chazelas
2017-09-10 05:54:48 +0700, Robert Elz: > Date:Sat, 9 Sep 2017 20:41:42 +0200 > From:Martijn Dekker > Message-ID: > > | Relevant here is that 'exec' is a special builtin (unlike 'command'). > |

[awk] print 1 > 2 > 3

2017-09-28 Thread Stephane Chazelas
Hi, from what I understand of: http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/utilities/awk.html awk's grammar. echo x file | awk '{print $1 > $2 ".txt"}' is meant to write "x\n" to "file.txt" And: awk 'BEGIN{print 1 > 2 > 3}' is meant to be the same as: awk 'BEGIN{print 1 >

Re: FYI: ksh88 (/usr/xpg4/bin/sh) is not actually POSIX compliant

2017-09-29 Thread Stephane Chazelas
2017-09-29 12:02:17 -0400, Chet Ramey: [...] > I have to check my ksh88 book, but I believe that ksh88 functions had > local scope for traps and options as well as variables. [...] Yes, you're right, thanks. I knew that was the case for ksh93's functions defined with the function f {...;} syntax

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-21 12:39:25 +0200, Andries E. Brouwer: > On Sat, Oct 21, 2017 at 09:26:04AM +0100, Geoff Clare wrote: > > > Linux allows two mounts to the same mount point. (I tested it with > > "mount --bind ..."; not sure if it would work with a "real" mount.) > > However, the files in the first mount

Re: [1003.1(2008)/Issue 7 0001165]: What is the working group's plan for stateful polling (e.g., kqueue, epoll), event loops (libuv) and coroutines (C++2a)?

2017-10-24 Thread Stephane Chazelas
2017-10-24 11:31:08 +0200, Joerg Schilling: [...] > Given that there is no standard for a VFS interface and the fact that the > Linux > VFS implementation is more than sub-optimal (see the discussions about > reiserfs > and Linux) it would be a bad idea to standardize something that is based

Re: UTF-8 locale & POSIX text model

2017-11-26 Thread Stephane Chazelas
2017-11-25 20:53:20 +0100, k...@keldix.com: [...] > > It just says those characters are the one constituting the > > portable character set. It doesn't specify the encoding other > > than it mandates the encoding of those characters to be > > invariant in the charsets in the system's supported

Re: UTF-8 locale & POSIX text model

2017-11-26 Thread Stephane Chazelas
2017-11-26 14:07:50 +0100, k...@keldix.com: [...] > > For instance, as currently specified, POSIX says that the > > output of the "locale" utility be suitable for reinput to the > > shell and requiring double-quote quoting in some cases. > > > > Using double-quote quoting is problematic because

Re: UTF-8 locale & POSIX text model

2017-11-22 Thread Stephane Chazelas
2017-11-22 16:27:15 +0100, Martijn Dekker: > Op 22-11-17 om 16:02 schreef Geoff Clare: > > Danny Niu wrote, on 22 Nov 2017: > >> > >> Q1: What is the rationale for not making POSIX an application of ASCII? > > > > So that systems which use other encodings (specifically

Re: Preserving standard input for background commands in scripts

2017-10-30 Thread Stephane Chazelas
2017-10-30 09:24:21 -0400, Chet Ramey: [...] > As it reads right now, a reasonable person could infer that `this activity' > means the behavior described by the rest of the paragraph (`shall be > considered...'), and that the /dev/null redirection doesn't happen if > stdin is explicitly redirected

Re: Testing if two files are on the same file system

2017-10-25 Thread Stephane Chazelas
2017-10-25 11:17:56 +0200, Martijn Dekker: [...] > I'd like to be able to do something like: > > if is onsamefs "$file1" "$file2"; then > ln "$file2" "$file1"# hard links are possible Should probably be: ln -f -- "$file2" "$file1" -- Stephane

Re: Testing if two files are on the same file system

2017-10-25 Thread Stephane Chazelas
2017-10-25 12:01:04 +0200, Martijn Dekker: [...] > > I'm not sure what the output of "LC_ALL=C df -P" should be for a > > mount point like a UTF-8 /home/stéphane > > That's a good point. I had actually added LC_ALL=C to my 'df' > invocation, more out of habit than anything. I should remove it.

Re: Testing if two files are on the same file system

2017-10-25 Thread Stephane Chazelas
2017-10-25 10:11:35 +0200, Vincent Lefevre: > On 2017-10-24 21:11:45 +0200, Joerg Schilling wrote: > > Nick Stoughton wrote: > > > > If you are correct, this is a Linux kernel bug. > > > > > > Why? The stat command is not standardized. The --file-system argument > > >

Re: Symlink behaviour [was; Testing if two files are on the same file system]

2017-10-26 Thread Stephane Chazelas
2017-10-25 22:50:09 +0100, Martijn Dekker: [...] > I think this means 'df' and all other utilities (and even basic libc > functions like fopen()) are required to follow symlinks given as > arguments, unless explicitly specified otherwise either by the spec or > (if a relevant option exists) by the

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-24 09:06:19 -0700, Nick Stoughton: > > If you are correct, this is a Linux kernel bug. > > Why? The stat command is not standardized. The --file-system argument > changes the output of %i to something other than the inode ... no bug. [...] Actually, the Linux man page for statfs(2)

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-24 10:22:42 +0100, Stephane Chazelas: [...] > stat implementations > [...] > Only the zsh stat builtin (can be loaded as > "zstat" to avoid overriding the system's stat for those that now > have added (an incompatible) one since) can avoid t

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-25 06:39:01 +0100, Stephane Chazelas: [...] > On FreeBSD, gnustat -fc%i returns 0 for everything including UFS > file systems. [...] Sorry, only if you're not root as hinted in the Linux statfs man page. You do get a non-zero value as root including for devfs and tmpfs on F

Re: Testing if two files are on the same file system

2017-10-24 Thread Stephane Chazelas
2017-10-24 16:01:22 -0400, Garrett Wollman: [...] > >> Nobody knows what f_fsid is supposed to contain (but see below). > > Actually, it is quite well known (just apparently not by the author of > that document). The fsid is used to generate NFS file handles. It's > supposed to be random and

Re: Preserving standard input for background commands in scripts

2017-10-31 Thread Stephane CHAZELAS
2017-10-31 11:38:37 +0100, Joerg Schilling: [...] > OK, the Bourne Shell can IO redirection only with a fork. [...] Except for builtins and functions (at least with some versions like Solaris 10's /bin/sh). That seems to also work for "eval", so one could also do: eval 'cmd <&3 3<&- &' 3<&0;

  1   2   3   4   >