Re: [1003.1(2013)/Issue7+TC1 0001066]: Solution proposal to the 2038 problem.

Vincent Lefevre wrote: > Note that we were talking about binary compatibility, not just > POSIX conformance. The behavior is undefined *by POSIX*. But an > implementation may define the behavior with negative time_t. In > such a case, the binary compatibility would be

Re: how is '(' recognized by the shell standard as a token?

Mark Galeck wrote: > > $ f( > dash: Syntax error: newline unexpected (expecting ")") > $ > > instead of trying to execute 'f(' Besides that you should reread the standard with respect to word limits in the shell command language, is there a specific reason why you

Re: Quoting: is "${foo-'a"b'"}" valid?

Chet Ramey wrote: > > But please explain (character by character) why you create an output that > > is in > > conflict with the reference implementation (a patched ksh88). > > `Character by character'? Really? > > (And obviously the so-called `reference implementation'

Re: Quoting: is "${foo-'a"b'"}" valid?

Vincent Lefevre wrote: > > > but the other shells regard them as special: > > > > > > $ foo=abcdef; echo "${foo#'ab'}" > > > cdef > > > > > > So, is this also unspecified like double quotes? Or should it > > > be specified that they are special, in which case, dash /

Re: "command" behaviour

Vincent Lefevre wrote: > > Indeed, and interpreting this requirement to exit with status 127 if > > the command is not found as meaning that: > > > > exec nonexistentfile > > > > always causes the shell to exit, in all circumstances, conflicts with > > XCU 2.8.1

Bugid 1013 and the dangerous rating of -L vs. -P

Hi, last night I thought about the problem again and it turned out that the example against -P in the etherpad, we had during the teleconference does not name a problem cause by "cd -P" but rather a problem caused by the existence of a symlink in general. For this reason, the named example

Re: Should aliases expand after 'command'?

Martijn Dekker wrote: > I always thought 'command' is suitable for bypassing both aliases and > shell functions. AT ksh93 defines a default alias >command='command ' > so that aliases after 'command' are expanded, but it is alone in that > behaviour, and 'command' can be

Re: when does PATH search stop?

Mark Galeck wrote: > Hello, > the shell standard section on Command Search and Execution, says  > command shall be searched for using the PATH environment variable as > described in XBD Environment Variables  > and that section says the value of PATH is split into a

Re: Should aliases expand after 'command'?

Dan Douglas wrote: > $ while IFS= read -ru 9 line; do > echo "$line" > for sh in bash ksh zsh mksh dash bb; do printf '%-8s%s\n' " ${sh}: > " "$("$sh" /dev/fd/8)" " ${sh}: " "$(exec -a sh -- "$sh" /dev/fd/8)"; > done 8< alias .echo="echo "

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

Stephane Chazelas wrote: > 2016-11-02 10:13:37 +, Geoff Clare: > [...] > > We believe that all modern shells are already using O_EXEC. The one > > notable shell that doesn't is ksh88 but I don't count that as modern, > > since ksh93 is its modern replacement. >

Re: Should aliases expand after 'command'?

Stephane Chazelas wrote: > See the related "bug" which I raised against ksh93 some time > ago: > > https://github.com/att/ast/issues/16 > It looks like that github site is the new home for ksh93. Is > anybody looking at the issues raised there or is there a >

Re: Should aliases expand after 'command'?

Dan Douglas wrote: > There's not much agreement however on what constitutes a "trailing > space". Almost every possible interpretation exists in some > implementation and even varies with compatibility modes in a few > cases. Some shells look eagerly to the next word without

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

Stephane Chazelas wrote: > OK, "Solaris 11 and its maintenance releases" make more sense > than "Solaris 11 FCS and later". Thanks for clarifying. This is how I thought Solaris always was maintained: There are updates to a specific version that grant not to

Re: Should "exec" run a shell function?

Geoff Clare <g...@opengroup.org> wrote: > Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 17 Jul 2017: > > In general, if Bourne Shell and ksh93 agree, this is most likely the right > > behavior unless you discovered a real bug. > > The intended

Re: Should "exec" run a shell function?

Stephane Chazelas wrote: > 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

Re: Environment of expansions and visibility of side-effect assignments

Robert Elz wrote: > if (vfork() == 0) { > for each redirect operator & word > expand the word > open/close/dup as required > execve(...) > } > > leaves the side effects of the expansions (as

Re: Environment of expansions and visibility of side-effect assignments

Geoff Clare wrote: > Robert Elz wrote, on 25 Jul 2017: > > > > Given the following command sequence ... > > > > VAR=${M=bla} /bin/echo ${N=bla} > /tmp/JUNK-${Q=bla} > > echo $M:$N:$VAR:$Q > > > > what is the "echo" on the 2nd line supposed to

Re: Environment of expansions and visibility of side-effect assignments

Robert Elz wrote: > Given the following command sequence ... > > VAR=${M=bla} /bin/echo ${N=bla} > /tmp/JUNK-${Q=bla} > echo $M:$N:$VAR:$Q > > what is the "echo" on the 2nd line supposed to print? > > It is clear (I think) that expanding VAR='' and N=bla is

Re: Environment of expansions and visibility of side-effect assignments

Jilles Tjoelker wrote: > > >From my metering, I know that on Solaris vfork() is 3x faster than fork() > > even tough the fork() implementation in SunOS uses CopyOnWrite since 1988. > > > As a result, I typically see aprox. 30% better performance with a > > "configure" > > run

Re: Environment of expansions and visibility of side-effect assignments

Robert Elz <k...@munnari.oz.au> wrote: > Date:Tue, 25 Jul 2017 19:06:13 +0200 > From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> > Message-ID: > <59777a85.lYd+zInvutTipp/s%joerg.schill...@fokus.fraunhofer.de> > >

Re: sh exit status ($?) for exec failures

Robert Elz wrote: > When the shell has to exec a utility, if the exec*() it performs fails, > it has to reflect that status (failure) back to the calling process > (usually for our purposes, the script). > > XCU 2.8.2 includes ... (lines wrapped for e-mail) > > 75455 If a

Re: Capturing standard error using command substitution and redirection

Robert Elz wrote: > When the { } are there there's no question the redirect on the compound > command itself happens first, and then the contents of that are executed, > so then it all works. > > Personally I think the "may be reversed" (not even "shall be") is a mistake, >

Re: Capturing standard error using command substitution and redirection

Robert Elz <k...@munnari.oz.au> wrote: > Date:Mon, 3 Jul 2017 11:45:30 +0200 > From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> > Message-ID: > <595a123a.dp23fbcbtystwzcf%joerg.schill...@fokus.fraunhofer.de> > > &

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

Sorry for the binary content in the first attempt to reply 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: Solaris 11 certification and broken links at www.opengroup.org

bin_6wp18NC7X.bin Description: Binary data

Re: SIGCHLD trap in a shell

Vincent Lefevre wrote: > I wonder how the following script is supposed to behave. > > The POSIX spec seems ambiguous about SIGCHLD trap in a shell. It says: > "[...] a signal specified using a symbolic name, without the SIG prefix, > as listed in the tables of signal

Re: SIGCHLD trap in a shell

Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote: > From my interpretation, only: > > dash, bosh (the POSIXyfied Bourne Shell), mksh and yash > > and probably zsh > > work as expected. BTW: I should have mentioned that this test cannot be done with

Re: SIGCHLD trap in a shell

Chet Ramey wrote: > That's all the standard can guarantee. The standard does not guarantee that > each child exit will generate a separate SIGCHLD delivery. There is also > nothing in the standard that speaks to what a shell, for instance, does > when it receives a signal.

Re: [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?)

Stephane Chazelas wrote: > 2017-05-16 17:29:13 +0100, Stephane Chazelas: ... > szsh a 0.763 > szsh b 0.622 > ksh93 a 0.667 > ksh93 b 0.464 > yash a 0.738 > yash b 0.429 > > In mksh, printf is not built-in which doesn't help. In all but > ksh93, that still does 5

Re: "-" operand to "sh"

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 would be possible > > to use "sh +m" in a useful way. >

quoting in shell parameter expressions

Hi, this is a question to Geoff Clare I would like to get a confirmation on how this expression: "${xxx-"a b c"}" is to be understood. In special, is "${xxx-" a quoted partial string or is "a b c" a quoted partial string Note that only ksh93 expands this to

Re: quoting in shell parameter expressions

Jilles Tjoelker wrote: > special treatment of $ { } until expansion time. Now that ${param#word} > exists which has its own quoting state for the inner word, that is no > longer possible. This was also taken advantage of to allow things like > your example "${xxx-"a b c"}"; the

Re: quoting in shell parameter expressions

Geoff Clare <g...@opengroup.org> wrote: > Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 20 Jun 2017: > > > > I would like to get a confirmation on how this expression: > > > > "${xxx-"a b c"}" > > > >

Re: quoting in shell parameter expressions

Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote: > Jilles Tjoelker <jil...@stack.nl> wrote: > > > special treatment of $ { } until expansion time. Now that ${param#word} > > exists which has its own quoting state for the inner word, that is no > >

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

Vincent Lefevre <vincent-o...@vinc17.net> wrote: > On 2017-05-24 16:15:03 +0200, Joerg Schilling wrote: > > I have no idea what "posh" targets, but given that: > > > > posh > > $ exit > > posh: exit: bad number > > I can't repro

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

Stephane CHAZELAS wrote: > I reported 3 as that was the first 3 I tested: > > $ 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 a given environment variable). Do you have a

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

Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> 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. > > > $ ./sh -o posix -c 'a=1; {

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

Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote: > 2017-05-24 16:15:03 +0200, Joerg Schilling: > > A configure script (if done correctly) is a script with _very_ > > pessimistic assumptions on portability. Given that "posh" completely fails > > here,

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

Stephane Chazelas wrote: > If your "configure" script works with "mksh" but not with > "posh", I suspect it's because that script is using non-POSIX > ksh extensions, as basically mksh is pdksh with a few fixes and > extensions added, while posh is pdksh with a few

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

Stephane Chazelas wrote: > 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

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

Stephane CHAZELAS wrote: > > > ZSH_EMULATION=sh CONFIG_SHELL=/usr/bin/zsh /usr/bin/zsh ./configure > > > > Ok this is what I get: > > > > ZSH_EMULATION=sh CONFIG_SHELL=/usr/bin/zsh /usr/bin/zsh ./configure > > ./configure:777: no matches found: conftest* > >

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

Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote: > 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 > > > > >

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

Robert Elz <k...@munnari.oz.au> wrote: > Date:Mon, 29 May 2017 11:47:04 +0200 > From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> > Message-ID: > <592bee18.kvZiYpLd6LS/Evf/%joerg.schill...@fokus.fraunhofer.de> > > | If t

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

Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote: > 2017-05-24 17:21:33 +0200, Joerg Schilling: > > Do you have a pointer to the POSIX text that forbids a subshell in this > > case > > when stdin is redirected? > [...] > > I don't know if you'll find

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

Robert Elz <k...@munnari.oz.au> wrote: > To get away from the dick waving "my shell is bigger than yours" > discussions for a minute ... > > In note 3745 attached to http://austingroupbugs.net/view.php?id=767 > Joerg Schilling proposes making a list of shells

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > In interactive mode, job control (-m) is enabled automatically. Some This is true for ksh, but not required by POSIX. > shells, such as FreeBSD sh, dash, mksh and heirloom-sh-050706, allow You are right for FreeBSD sh, dash and mksh, but the beirloom

Re: rm -rf ./ ../

Stephane CHAZELAS wrote: > 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

Re: "-" operand to "sh"

Jilles Tjoelker wrote: > 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

Re: rm -rf ./ ../

Stephane Chazelas wrote: > So pdksh/zsh globs are currently only non-compliant in that they > may not match what readdir() returns, but in anycase, > applications cannot make much assumption on whether "." or ".." > should be returned, so that compliance issue is not

Re: "-" operand to "sh"

Stephane CHAZELAS wrote: > Let's face it, a shell that would leave the "m" option "on" when > the user explicitly requested it to be "off" in > > sh +m > > is a bug (and in this case also a conformance bug for shells > that support UP though it may need to be

Re: Quoting the POSIX specification

Yann Régis-Gianas wrote: > Dear colleagues, > > I am a researcher at University Paris Diderot and in collaboration with > Ralf Treinen and Nicolas Jeannerod, we are implementing a "trustworthy" > open source parser for POSIX shell. One argument to convince people

Re: compound-list

Stephane CHAZELAS wrote: > Sorry, correcting my correction. I read the above two quickly. > It seems I was right. In TC1 and before, it does look like > indeed that in > > < file until ... > > That "until" is required to be a WORD as per: > > cmd_word : WORD

Re: compound-list

Stephane CHAZELAS wrote: > > POSIX does not allow > > > > f() cmd > > > > but only > > > > f() { cmd; } > > > > and even the Bourne Shell allows (documents) this only for the case that > > "cmd" is a compound command that (like we discussed) does not

Re: What shell implementations to consider

Thorsten Glaser wrote: > Stephane Chazelas dixit: > > >ksh extensions, as basically mksh is pdksh with a few fixes and > > ?a few?, sure, just way over a decade worth of them, and neither > pdksh nor its other derivatives share about 90% of them. And an interesting fact:

Re: Quoting the POSIX specification

Yann Régis-Gianas <y...@pps.univ-paris-diderot.fr> wrote: > Le ven. 9 juin 2017 à 16:32, Joerg Schilling < > joerg.schill...@fokus.fraunhofer.de> a écrit : > > > Yann Régis-Gianas <y...@pps.univ-paris-diderot.fr> wrote: > > If you plan to use the BNF gramma

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

Stephane CHAZELAS wrote: > 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

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

Stephane CHAZELAS wrote: > The discussion (on austin group) I was remembering of was in > April 2010, with "Assignment with command: export only, or sets > variable, too?" as the subject. > > Followup on dash mailing list at >

Re: Quick timey question.

Robert Elz wrote: > If yu can deal with timespec's instead of timeval's (and you really should) > you can easily > > #define gettimeofday(t, trash) glock_gettime(CLOCK_REALTIME, (t)) > > and barely notice the difference. If you need timevals, it is not hard > to

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,

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

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

Alan Coopersmith <alan.coopersm...@oracle.com> wrote: > On 10/ 1/17 04:10 AM, Joerg Schilling wrote: > > Is Oracle planning to run a SUSv7-tc2 certification? > > I don't know which version we plan to certify against next, and probably > couldn't pre-announce it here if I

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

Geoff Clare wrote: > > What I have in mind for "${a-"*"}" is [...] > > This topic was discussed at great length when we resolved bug 221 > back in 2010. I don't think there is anything to be gained from > starting a new discussion of "${a-"*"}". Since I did not yet see any

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

Martijn Dekker wrote: > > > > the builtin command "times" does not create POSIX compliant output. > > 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 '{ {

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

Martijn Dekker <mart...@inlv.org> wrote: > Op 01-10-17 om 14:43 schreef Joerg Schilling: > > The standard does not claim that a function has to be executed the same way > > as > > a compound ist would have been executed, or do you see such a claim in the > >

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

Jilles Tjoelker wrote: > However, things like "${a-"*"}" are unspecified (in practice, the > asterisk may either be literal or generate pathnames, depending on the > shell). With > > cat < ${a-"*"} > EOF echo "${a-"*"}" is equivalent to "echo *" for the Bourne Shell, ksh88,

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

Chet Ramey wrote: > > ksh88 has POSIX compliant functions, see: > > > > ksh -c 'a=0; a() { a=12; } ; a; echo $a' > > Nobody is arguing whether or not unqualified assignment statements in ksh88 > modify global variables. This is not the behavior that makes ksh88 > functions

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

Chet Ramey wrote: > > But this is what you get with ksh93: > > > > ksh93 -c 'a=0; a() { local a; a=12; } ; a; echo $a' > > ksh93[1]: local: not found [No such file or directory] > > 12 > > It doesn't work even if you use `typeset', which is accepted. But this would prevent

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

"Schwarz, Konrad" wrote: > Perhaps I haven't understood the full import, but ksh92 has an additional > function syntax (function name { body; }), where "function" is a keyword, > that provides local variables declared with typeset. > > "The New Kornshell" states > > >

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

Chet Ramey wrote: > ksh had functions dating from the early 1980s in its original incarnation > as a form interpreter. Korn mentions functions as one of the first things > he added to the Bourne shell. I don't know whether ksh-83 had the SVR2 > function declaration syntax in

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

Martijn Dekker wrote: > > This is an interesting behavior, but it is not related to local/dynamic > > scoping, since this is a test whether a function is run in a sub-shell. > > That's easy to disprove. I just did the the following on my Solaris 11.3 > VM using

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

Martijn Dekker wrote: > > Such a text is however missing in POSIX. > > It is not missing. As previously shown (and you removed from the quoted > text), the POSIX definition of a "function" incorporates the POSIX > definition of a "Compound Command". And that says: > > {

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

"stephane.chaze...@gmail.com" wrote: > Note that I'm not under the impression that ksh93 aimed for > POSIX compliant. For instance, it did explicitely break POSIX > compliance (and backward compatibility) when the <> redirection > operator changed from being short

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)?

Steffen Nurpmeso wrote: > |This is why I propose that POSIX goes into another direction: standardise > |an event loop. By doing this, we're not only avoiding the entire discussion > > What a terrible idea! You even want to take away the possibility > to implement the event

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

Stephane Chazelas wrote: > However if "dir" is (was) ".", the inode of "." will stay > unchanged (the cwd case you mentioned). > > /tmp/1$ sudo mount -t tmpfs x $PWD > /tmp/1$ ls -id . $PWD > 311402 . 2 /tmp/1 > $ df -P . $PWD > Filesystem

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

Vincent Lefevre wrote: > as with "stat --file-system --format=%i", the output is 0 for any file > on a tmpfs. If you are correct, this is a Linux kernel bug. The original tmpfs implementation on Solaris does not have this problem. Jörg -- EMail:jo...@schily.net

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)?

Stephane Chazelas <stephane.chaze...@gmail.com> wrote: > 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 d

Re: UTF-8 locale & POSIX text model

Joseph Myers wrote: > On Sat, 25 Nov 2017, k...@keldix.com wrote: > > > systems, and also implementations that can conform using UTF-16 and > > different 8-bit codesets. For instance 'A' is coded x0041 (two bytes) in > > UTF-16 > > and x41 (only one byte) in cp850, and

Re: Minutes of the 30th November 2017 Teleconference: Bug 1064

Robert Elz wrote: > > If we switch the implementation to no longer use a static buffer, > then we are going to have to find some way to return a (non-const) > version of "." in cases like dirname(NULL) or dirname("") (this > latter one not literally, obviously) where we

Re: Preserving standard input for background commands in scripts

Martijn Dekker wrote: > Question: should the last sentence quoted above also apply if standard > input is explicitly redirected to itself? E.g., when running the > following with job control disabled (e.g. as a script) and standard > input on a terminal: > > if [ -t 0 ];

Re: Preserving standard input for background commands in scripts

Robert Elz wrote: > Date:Sun, 29 Oct 2017 21:47:43 + > From:Martijn Dekker > Message-ID: <6432d459-75de-0afe-6716-7960e7a0a...@inlv.org> > > | | In all cases, explicit redirection of standard input shall > | | override

Re: Preserving standard input for background commands in scripts

Stephane Chazelas wrote: > 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

Re: Preserving standard input for background commands in scripts

Robert Elz <k...@munnari.oz.au> wrote: > Date:Mon, 30 Oct 2017 11:10:59 +0100 > From: Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> > Message-ID: > <59f6fab3.e5lk2pfuroy2omt4%joerg.schill...@fokus.fraunhofer.de> > > | Just

Re: Preserving standard input for background commands in scripts

Stephane Chazelas wrote: > So an application has to do: > > cmd < /dev/null & > > if it wants to make sure cmd is redirected from /dev/null. > > and: > > { cmd <&3 3<&- & } 3<&0 > > if it wants to work around that (inconsistent) (mis-)feature of > some shells. > >

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

Nick Stoughton wrote: > > 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. Whether it is standardized or not, it prints

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

> Hmm... on Linux, there can be several tmpfs mounts and they all have the > same file system name in the first column. Example: > > tmpfs 33039212 0 33039212 0% /dev/shm > tmpfs 33039212 3277180 29762032 10% /run > tmpfs 5120 0 5120 0% /run/lock > tmpfs 33039212 0

Re: Preserving standard input for background commands in scripts

Stephane CHAZELAS <stephane.chaze...@gmail.com> wrote: > 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

Re: Preserving standard input for background commands in scripts

Stephane CHAZELAS wrote: > There's no pipe in: > > { cmd <&3 3<&- & } 3<&0 > pid=$! > > and POSIX does require $! to contain the pid of the process that > executed cmd there. > > As already discussed, the fact that redirected compound commands > were run in a

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Robert Elz wrote: > Oh, one more thing about patterns - a question this time, though the > answer might end up suggesting more text that needs to be in > the standard. > > If I have > > var='a*"?"' > > and then I do > > echo $var > > what should the result be?

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Geoff Clare wrote: > Robert Elz wrote, on 27 Apr 2018: > > > > Oh, one more thing about patterns - a question this time, though the > > answer might end up suggesting more text that needs to be in > > the standard. > > > > If I have > > > >

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Shware Systems wrote: > According to XCU 2.6.5, it's treated literally only when double quoted, e.g. > "$var", otherwise quote removal should still occur on the variable's contents > after any field splitting... XCU 2.6.5 explains what happens after parameter expansion,

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Robert Elz wrote: > We could require, than when stored in a variable, we quote > things in pattern style "quoting" rather than shell style, that is, > to take the example from my immediately previous message, > > $SHELL -c 'var="[a-e][?].*";printf "%s\n" ${var}' > >

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Robert Elz wrote: > But it looked right, so I changed (not yet committed, nor are the other > bug fixes I have made to this) the NetBSD sh to produce the same > result as bash: > > ${SH} -c 'var="[a-e]\\?.*";printf "%s\n" ${var}' > a?.?? > b?.?? >

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Geoff Clare wrote: > In summary: the need for a way to store a pattern in a variable such > that a pattern-magic character can be treated literally is a reason to > keep the first paragraph of 2.13.1 as-is and say that shells which > behave differently than bash here do not

Re: More questions/comments on XCU 2.13 (sh Pattern Matching)

Robert Elz wrote: > The examples with "" characters I expect will simply remain as they > are in all shells, and the code I have been in the process of writing > to allow that to "work" (based on the assumption that there is no reason > why not - and even now, except that it

Re: Laundry list

Geoff Clare wrote: > > Since I believe I was the first who implemented a filesystem without . and > > .. > > (my COW filesystem WOFS from 1990/1991), I would be happy if that was > > allowed. > > If . and .. don't exist in the file system, then POSIX *requires* that > the

Re: can [[:digit:]] match something other than 0123456789?

Hans Åberg wrote: > >> |I asked a person who speaks japanese and he told me that > >> | > >> | "\u4e00\u4e8c\u4e09" > >> | > >> |is similar to > >> | > >> | "one two three" > >> | > >> |and this is not used for computing. > >> > >> If i recall correctly this has been

Re: can [[:digit:]] match something other than 0123456789?

Hans Åberg <haber...@telia.com> wrote: > > > On 16 May 2018, at 10:29, Joerg Schilling > > <joerg.schill...@fokus.fraunhofer.de> wrote: > > > > Robert Elz <k...@munnari.oz.au> wrote: > > > >> How does one specify a locale for som

Re: can [[:digit:]] match something other than 0123456789?

Robert Elz wrote: > How does one specify a locale for some area using Latin as its > language, where I V X L C D M are the digits ? how do you like to specify a hexadecimal number in this locale? Jörg -- EMail:jo...@schily.net(home) Jörg Schilling

Re: can [[:digit:]] match something other than 0123456789?

Robert Elz wrote: > would be easy, but you say it alao has to look for > > (c) [[:latindigs:]]+ > (c) [[:vdigits:]]+ > > (and how many more)? This is actualy kind of important, as > > (c) MMXVI > > type strings are not uncommon in certain environments

Re: can [[:digit:]] match something other than 0123456789?

Geoff Clare wrote: > Stephane Chazelas wrote, on 15 May 2018: > > > > OK, so to rephrase and make sure I understand correctly. In > > locales other than C, [[:digit:]] will be guaranteed to match on > > 0123456789 only but not [0-9]. 0123456789

  1   2   3   4   5   >