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

The list looks to be clogged, none of the recent messages are getting through (so I added a few cc's in the hope that at least one of you can find out what is going on) - or I would have replied to my own message on this thread... (but I haven't seen it yet, and I don't keep copies) Off list Mark

Re: Rationale behind no atomicity guarantees for directory operations

Date:Fri, 2 Sep 2016 07:36:01 +0100 From:Gian Ntzik Message-ID: <877fauolke@imperial.ac.uk> | What is the rationale behind not having the same requirement for | functions working with directories, such as mkdir(), rmdir() and |

Intended difference between waitpid() and waitid() ??

The spec (C165) for wait() (though this is only relevant to waitpid()) says ... If waitpid( ) was invoked with WNOHANG set in options, it has at least one child process specified by pid for which status is not available, and status is not available for any process

Re: Intended difference between waitpid() and waitid() ??

Date:Sun, 6 Nov 2016 23:19:30 -0500 From:Shware Systems Message-ID: <1583d033695-e5e-e...@webprd-a49.mail.aol.com> | I believe the difference | is to take into account a pid may be both a specific process id and | process group id for a

Re: Intended difference between waitpid() and waitid() ??

Date:Mon, 7 Nov 2016 09:51:32 + From:Geoff Clare Message-ID: <20161107095132.GA14686@lt.loopback> | I am fairly certain the difference is not intentional. OK, thanks. | All certified UNIX systems give an ECHILD error from waitid() |

Re: Should aliases expand after 'command'?

Date:Mon, 24 Oct 2016 11:09:13 +0100 From:Geoff Clare Message-ID: <20161024100913.GA17316@lt.loopback> | Perhaps for Issue 8 we should consider tightening the standard to | require that any predefined alias with the name of a standard utility

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

Date:Tue, 25 Oct 2016 09:54:30 +0100 From:Geoff Clare Message-ID: <20161025085430.GA3974@lt.loopback> | I doubt if I have ever used: | | ls .. | cd .. | | because it is more natural to use: | | cd .. | ls This entirely

Re: Siginfo_t question:

Date:Mon, 14 Nov 2016 16:33:48 -0800 From:Philip Guenther Message-ID:

Re: Siginfo_t question:

Date:Mon, 14 Nov 2016 14:15:20 -0800 From:Philip Guenther Message-ID:

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

Without getting into the specifics of the proposed change yet, I'd like someone to explain just what is the fascination with using -C and '>' for making lock files? The time honoured way of making lock files (since way, way, back) is via the use of link(2) (or ln(1)) which has always provided for

Re: 0001038: Specification relies upon unspecified behaviour

Date:Thu, 16 Mar 2017 23:06:14 -0400 From:Wayne Pollock Message-ID: | echo "\$ foo" | produce: | $ foo Yes. | \$ foo No. | The shall retain its special meaning as | an

Re: Minutes of the 9th March 2017 Teleconference

Date:Fri, 10 Mar 2017 12:12:57 + From:Andrew Josey Message-ID: <90d2058a-5014-4f9c-95f9-51dba40af...@opengroup.org> | Bug 0001038: Specification relies upon unspecified behaviour OPEN |

Re: Minutes of the 9th March 2017 Teleconference

Date:Mon, 13 Mar 2017 17:34:52 -0400 From:shwares...@aol.com Message-ID: <7c52d8.998fa7e.45f86...@aol.com> | Just so people know, most of those comments on the etherpad aren't mine. OK, apologies if I mis-attributed anything, I had never looked at the etherpad

Re: [1003.1(2016)/Issue7+TC2 0001154]: Add 'rm -v'

Date:Wed, 2 Aug 2017 06:13:02 + From:Austin Group Bug Tracker Message-ID: <810aa1250868693f1501980395894...@austingroupbugs.net> In this ,,, | while [ $? -eq 0 ]; do | set -- * | test $# -gt 0 || break | rm -fr --

Re: Should "exec" run a shell function?

Can we forget about irrelevant side issues related to pipelines, etc? As far as syntax and sematics go, "exec" is a special built-in that is a very close cousin of "exit" - both cause the current shell environment to terminate, the only difference is where the exit status comes from (and perhaps

Re: Should "exec" run a shell function?

Date:Mon, 17 Jul 2017 15:45:08 +0100 From:Geoff Clare <g...@opengroup.org> Message-ID: <20170717144508.GA18920@lt2.masqnet> | Robert Elz <k...@munnari.oz.au> wrote, on 17 Jul 2017: | > | > Can we forget about irrelevant side issues r

Re: Should "exec" run a shell function?

Date:Tue, 18 Jul 2017 10:48:40 +0100 From:Geoff Clare Message-ID: <20170718094840.GA21862@lt2.masqnet> | Okay, here are my suggested changes. Some relatively minor comments ... | On page 2397 line 76687-76689 section 2.14 exec, change: |

Re: Should "exec" run a shell function?

Date:Tue, 18 Jul 2017 09:42:23 -0500 From:Eric Blake Message-ID: <95e69c19-766e-2686-b34c-8ccbd50e1...@redhat.com> | I wonder if it is worth noting that you can also use 'env printf' | instead of '(exec printf)' to get the same PATH lookup

Re: Should "exec" run a shell function?

Date:Tue, 18 Jul 2017 14:45:11 +0100 From:Geoff Clare Message-ID: <20170718134511.GB24639@lt2.masqnet> | I think "command" is the right word here. It's talking about a specific | usage of "exec" (with no operands) in a command, not about the

Re: Should "exec" run a shell function?

Date:Tue, 18 Jul 2017 16:52:02 +0100 From:Geoff Clare Message-ID: <20170718155202.GA26495@lt2.masqnet> | I really don't understand why you have a problem with this usage. I don't. I don't have a problem with the original either. That is,

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

Date:Tue, 25 Jul 2017 16:53:54 +0100 From:Geoff Clare Message-ID: <20170725155354.GB2553@lt2.masqnet> | The context here is a list of items that comprise a shell or utility | environment. This item in the list is concerned with what files are

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

Date:Tue, 25 Jul 2017 15:11:58 +0100 From:Geoff Clare Message-ID: <20170725141158.GA6514@lt2.masqnet> | The $M value is explicitly unspecified (2.9.1, second sub-bullet of the | second bullet item). Ah, yes, I see that now, thanks - the

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

Date:Tue, 25 Jul 2017 19:06:13 +0200 From:Joerg Schilling Message-ID: <59777a85.lYd+zInvutTipp/s%joerg.schill...@fokus.fraunhofer.de> | ash does not use vfork() at all. And life is a continuous process of learning new things -

Environment of expansions and visibility of side-effect assignments

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 correct there, and all shells I tested did that,

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

Date:Wed, 26 Jul 2017 18:27:43 +0200 From:Joerg Schilling Message-ID: <5978c2ff.CLQ2yfNU3QmKah/w%joerg.schill...@fokus.fraunhofer.de> | You would need: | repair_mods_from_the_child(); | } | | if you

sh exit status ($?) for exec failures

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 command is not found, the exit status shall be 127.

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

Date:Sat, 1 Jul 2017 18:30:59 -0400 From:Shware Systems Message-ID: <15d00474c8b-973-b...@webprd-a49.mail.aol.com> | A shell can use more codes as an extension, Yes, I know that. | but this is not recommended to leave as much room for

Re: Capturing standard error using command substitution and redirection

Date:Mon, 3 Jul 2017 11:45:30 +0200 From:Joerg Schilling Message-ID: <595a123a.dp23fbcbtystwzcf%joerg.schill...@fokus.fraunhofer.de> | This is not a bug, but a design decision. One man's design decision is another man's bug

Re: [1003.1(2016)/Issue7+TC2 0001154]: Add 'rm -v'

Date:Tue, 27 Jun 2017 23:57:14 +0200 From:Job Snijders Message-ID: <20170627215714.xijct2ul2yaybpb6@Vurt.local> | Do you have a suggestion how to improve the phrasing? I would say "the name is unlinked" rather than "files are deleted". kre

Re: SIGCHLD trap in a shell

Date:Tue, 25 Apr 2017 15:21:24 +0200 From:Vincent Lefevre Message-ID: <20170425132124.ga7...@cventin.lip.ens-lyon.fr> I see Jillles has said much the same thing while I was preparing this, but ... | I wonder how the following script is

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

Date:Wed, 3 May 2017 17:19:06 +0100 From:Stephane Chazelas Message-ID: <20170503161906.ga9...@chaz.gmail.com> | Even for BREs, the term "back-reference" doesn't make much sense | in this context. It could, but it is probably not the

Shell parameter expansions involving '#"

Hi, For NetBSD, I've just created a shell test of expansions where there is a '#' involved.. The test includes the following comments... # # $# looks like it should be so simple that it doesn't really # need a test of its own, and used in that way, it really doesn't. # But

Re: Shell parameter expansions involving '#"

Date:Mon, 15 May 2017 10:03:04 +0100 From:Geoff Clare Message-ID: <20170515090304.GA12956@lt2.masqnet> Thanks for the reply. | Explicitly unspecified in XCU 2.6.2. Oh, sorry, I should have been clearer, I know that. I will however add extra

Apologies for the mess with the notes I just added

I added a note to the wrong issue (1037) - then added it again to the correct one (1036) and deleted it from 1037... Apologies... kre

Re: SIGCHLD trap in a shell

Date:Thu, 11 May 2017 11:14:13 +0200 From:Vincent Lefevre Message-ID: <20170511091413.ga17...@zira.vinc17.org> | I agree, but SIGCHLD could still be useful to know that at least | a process has terminated, and that "wait" should be used

Re: SIGCHLD trap in a shell

Date:Wed, 10 May 2017 14:44:43 +0200 From:Vincent Lefevre Message-ID: <20170510124443.gd25...@cventin.lip.ens-lyon.fr> | But wouldn't it be useful to have the list of terminated processes as | a new POSIX feature for shells? Yes, it

Re: SIGCHLD trap in a shell

Date:Wed, 10 May 2017 08:02:11 -0400 From:shwares...@aol.com Message-ID: <2557dd.2e673a3d.46445...@aol.com> | Still, the effects on the environment should be the same, as separate | utility or built-in, including signal generation... No, Joerg is right - nothing

Re: SIGCHLD trap in a shell

Date:Wed, 10 May 2017 14:35:28 +0200 From:Vincent Lefevre Message-ID: <20170510123528.gc25...@cventin.lip.ens-lyon.fr> | Well, in any case, I meant that for | | `/path/to/external/command` | | the SIGCHLD can either be due to

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

Date:Tue, 16 May 2017 17:29:13 +0100 From:Stephane Chazelas Message-ID: <20170516162913.gd3...@chaz.gmail.com> | Sorry about that. I hadn't seen that message at the time I | replied. No, no problem, it was my fault - I should have

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

Date:Tue, 16 May 2017 18:46:39 +0100 From:Stephane Chazelas Message-ID: <20170516174639.ga19...@chaz.gmail.com> | Actually, even for a handful of arguments, and even with gawk, | it seems it's generally quicker to use awk in my tests:

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

Date:Wed, 17 May 2017 10:05:08 +0100 From:Stephane Chazelas Message-ID: <20170517090508.gb6...@chaz.gmail.com> | The initial question was about round-tripping "$@", so an | arbitrary number of arguments. Ah yes, you're right, it was

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

Date:Mon, 15 May 2017 18:36:58 +0200 From:Steffen Nurpmeso Message-ID: <20170515163658.b7ljs%stef...@sdaoden.eu> | Is it at all possible to store the parameter stack in a variable | "x" in order to restore it exactly "as-is", in the shell?

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

Date:Tue, 16 May 2017 10:03:56 +0700 From:Robert Elz <k...@munnari.oz.au> Message-ID: <14296.1494903...@andromeda.noi.kre.to> | Just remember to always quote variable references "$x" And then I see I forgot in ... $ stack="$(

Re: Shell parameter expansions involving '#"

Date:Mon, 15 May 2017 17:39:41 -0400 From:shwares...@aol.com Message-ID: <9ac89.7ef84acb.464b7...@aol.com> | I'm thinking 'foo=$# ${#foo##pat}' There is only ever one modification operator allowed in a (standard) variable expansion, that can be the prefix '#'

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

Date:Tue, 16 May 2017 10:03:56 +0700 From:Robert Elz <k...@munnari.oz.au> Message-ID: <14296.1494903...@andromeda.noi.kre.to> I keep replying to my own mail. This is really not a good sign! | Alternatively, you could implement this as an extern

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

Date:Tue, 16 May 2017 07:41:43 +0100 From:Stephane Chazelas Message-ID: <20170516064143.ga3...@chaz.gmail.com> | Or just write it as quote() (...) instead of quote() { ...;} Yes, as you would have seen later, I mentioned that in a

Re: compound-list

Date:Tue, 13 Jun 2017 00:02:34 +0200 From:Jilles Tjoelker Message-ID: <20170612220234.ga26...@stack.nl> | 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

Re: quoting in shell parameter expressions

Date:Tue, 20 Jun 2017 23:17:01 +0200 From:Jilles Tjoelker Message-ID: <20170620211701.ga90...@stack.nl> | (for example, expand a | variable literally if it is set and generate pathnames otherwise using | "${v-"*"}"). Yes, it does - however

Re: quoting in shell parameter expressions

Date:Tue, 20 Jun 2017 11:26:54 -0400 From:shwares...@aol.com Message-ID: | I thought we touched upon this also in discussing adding $'...', with the | resolution the arguments were WORDs in the grammatical sense and to be |

Re: quoting in shell parameter expressions

Date:Tue, 20 Jun 2017 16:02:10 +0200 From:Joerg Schilling Message-ID: <59492ae2.x1jxamf6tbnxjnad%joerg.schill...@fokus.fraunhofer.de> | While most of the corner cases could be correctly identified on how to | expand them, the

Re: fprintf, snprintf, etc., %n and overflow on the return value

Date:Tue, 23 May 2017 02:10:23 +0200 From:Vincent Lefevre Message-ID: <20170523001023.ga19...@zira.vinc17.org> | If the intent were to have "int" everywhere related to sizes in the | printf context, then why is the second argument of

Re: incorrect example for "export"

Date:Wed, 24 May 2017 15:40:07 +0200 From:Joerg Schilling Message-ID: <59258d37.h5t6p4p9cd52ubz7%joerg.schill...@fokus.fraunhofer.de> | If you later assign a value to that variable, the "export FOO" | command just sets up the

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

Date:Mon, 29 May 2017 14:38:02 +0200 From:Joerg Schilling Message-ID: <592c162a.syoz+dozzpogtqep%joerg.schill...@fokus.fraunhofer.de> | The problem is that I have a FreeBSD system available for testing, | but not a NetBSD

Re: "-" operand to "sh"

Date:Sat, 3 Jun 2017 21:07:10 +0100 From:Stephane CHAZELAS Message-ID: <20170603200710.gb13...@chaz.gmail.com> | Yes, that's it. Looking at the source and testing with a PDP11 | emulator, the initial version of the Bourne shell in

Re: rm -rf ./ ../

Date:Wed, 7 Jun 2017 20:56:17 +0100 From:Stephane CHAZELAS Message-ID: <20170607195617.gf5...@chaz.gmail.com> | I imagine that text was there for some reason. I have always thought that what was important was the "one" and that the

Re: "-" operand to "sh"

Date:Sat, 3 Jun 2017 23:28:24 +0100 From:Stephane CHAZELAS Message-ID: <20170603222824.gc13...@chaz.gmail.com> | If the point was to be "safe"/"pedantic" and allow the script to | be called by any name I see no particular advantage

Re: compound-list

Date:Thu, 15 Jun 2017 16:41:29 +0200 From:Joerg Schilling Message-ID: <59429c99.j3ycveab5syr2msh%joerg.schill...@fokus.fraunhofer.de> First, most of this discussion on what should be implemented (which is another way of saying

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

Date:Fri, 16 Jun 2017 17:32:44 +0100 From:Stephane CHAZELAS Message-ID: <20170616163244.ga4...@chaz.gmail.com> | Is it really? The text that says it is still there. Line 75508 in TC2 | I do remember it was discussed some time ago

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

OK, when I reread the line in question more carefully, I see that it only applies in the case where there is a command word (which is not...) I think left to right is now specified (in all cases) as earlier it says... the following expansions, assignments, and redirections shall all be

${LINENO} in functions

The definition of the LINENO variable (from 7 TC2 XCU section 2.5.3, page 2352, lines 74935-7) says ... Set by the shell to a decimal number representing the current sequential line number (numbered starting with 1) within a script or function before it executes each

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

Date:Wed, 24 May 2017 20:51:25 +0200 From:Joerg Schilling Message-ID: <5925d62d.mr6gk0tc0ybr6h6k%joerg.schill...@fokus.fraunhofer.de> | The problem would be if there is deviating behavior only between the shells | that are

Re: [1003.1(2016)/Issue7+TC2 0001154]: Add 'rm -v'

Date:Mon, 23 Oct 2017 16:38:44 + From:Job Snijders Message-ID: | What would be the next step in the process to move something forward? Do I | have to request the item is

Handling of a64l()/l64a() when long > 32 bits

We (NetBSD) have had a bug report that our a64l() does not behave correctly - where my reading of the standard is that it does... The issue is when long is > 32 bits (64 bits in the case in question), and the value that was converted by l64a() is a value which, if it were in a 32 bit signed

Re: Handling of a64l()/l64a() when long > 32 bits

Date:Thu, 14 Dec 2017 15:57:49 -0500 From:Shware Systems Message-ID: <16056d1a8d5-171b-a...@webjas-vaa080.srv.aolmail.net> | The reason I see why arbitrary negative values force the behavior to be | unspecified [...] That isn't what I wanted

Re: [1003.1(2008)/Issue 7 0001064]: basename() and dirname(): Specification is not complete enough to allow existing thread-unsafe implementations

One final question about the intent for basename() / dirname() ... With the current (Issue7.TC2) wording of how these functions are defined, it is clear that the sequence bn1 = basename(buf1); bn2 = basename(buf2); leaves bn1 undefined (the value may have been modified.) The

Re: Handling of a64l()/l64a() when long > 32 bits

Date:Fri, 15 Dec 2017 08:01:39 +0100 From:Ed Schouten Message-ID:

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

Unfortunately I think bug 1034 needs to be reopened. [Ed Schouten ]: | Yeah. NetBSD is already on the right track in that it already uses the | proper prototypes (with 'char *' arguments). It does (it didn't, for about 3 weeks, late April to early May, 2008), and most NetBSD

Re: Preserving standard input for background commands in scripts

Date:Mon, 30 Oct 2017 11:10:59 +0100 From:Joerg Schilling Message-ID: <59f6fab3.e5lk2pfuroy2omt4%joerg.schill...@fokus.fraunhofer.de> | Just as a hint: the implicit redirection to /dev/null happens at the moment | when a

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

Date:Wed, 18 Oct 2017 15:01:23 +0200 From:Martijn Dekker Message-ID: <4d781f3b-085c-d2ca-1912-b08410266...@inlv.org> | Is there a way, using POSIX shell and utilities, to reliably test if two | files are on the same file system? I have been

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

Date:Wed, 25 Oct 2017 11:17:56 +0200 From:Martijn Dekker Message-ID: | if is onsamefs "$file1" "$file2"; then | ln "$file2" "$file1"# hard links are possible | else | ln -s "$file2"

Re: Preserving standard input for background commands in scripts

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 this activity. That last sentence just shouldn't be

Re: [1003.1(2016)/Issue7+TC2 0001105]: problems with backslashes in awk strings and EREs

Date:Wed, 9 May 2018 09:18:37 +0100 From:Geoff Clare Message-ID: <20180509081837.GA24339@lt2.masqnet> | In the lexical token ERE when not inside a bracket expression, | the sequence shall represent itself. Otherwise undefined. Does it

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

Date:Fri, 27 Apr 2018 15:06:52 +0200 From:Joerg Schilling Message-ID: <5ae3206c.gzrnd81xboh3e0x7%joerg.schill...@fokus.fraunhofer.de> | Since bash seems to be the only shell that works this way, Until I changed the NetBSD sh

Re: Minutes of the 26th April 2018 Teleconference

Date:Fri, 27 Apr 2018 11:54:15 +0100 From:Andrew Josey Message-ID: This is kind of odd... | Attendees: | Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR | Joerg Schilling, FOKUS

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

Date:Fri, 27 Apr 2018 11:03:57 +0200 From:Joerg Schilling Message-ID: <5ae2e77d.95ubF707FXNl6/H/%joerg.schill...@fokus.fraunhofer.de> First, a (minor) apology - I should have made it clear that, yes, "set +f" was intended, and

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

Date:Fri, 27 Apr 2018 10:00:50 +0100 From:Geoff Clare Message-ID: <20180427090050.GA2538@lt2.masqnet> | I believe the former text is misleading and should be deleted. It is | effectively duplicating the requirements regarding backslashes

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

Date:Fri, 27 Apr 2018 09:33:49 -0400 From:Shware Systems Message-ID: <163074f534e-c83-4...@webjas-vaa062.srv.aolmail.net> | For my analysis, 2.6.5 says it is results which are subject to field splitting, Yes, but irrelevant here | with the

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

Date:Fri, 27 Apr 2018 15:24:30 +0100 From:Geoff Clare Message-ID: <20180427142430.GB9716@lt2.masqnet> | This discussion seems to have come round to the same issue that was | raised recently in some comments in bug 1190, specifically Stephane's

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

Date:Fri, 27 Apr 2018 15:17:41 +0200 From:Joerg Schilling Message-ID: <5ae322f5.uw3u84gim9o+bvrx%joerg.schill...@fokus.fraunhofer.de> | See my recent reply, this does not result in a quoted \. Of course it doesn't - no-one

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

Date:Fri, 27 Apr 2018 15:23:10 +0200 From:Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> Message-ID: <5ae3243e.8dyd5s4eftmrpyui%joerg.schill...@fokus.fraunhofer.de> | Robert Elz <k...@munnari.oz.au> wrote: | | > But it looked right,

Re: Laundry list

Date:Fri, 27 Apr 2018 15:38:19 +0100 From:Geoff Clare Message-ID: <20180427143819.GA10446@lt2.masqnet> Completely changing the topic ... | In the unlikely event we do another TC, With no supporting evidence whatever (not even rumor) I had

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

Date:Fri, 27 Apr 2018 16:20:01 +0200 From:Joerg Schilling Message-ID: <5ae33191.adgpivkbwgx8dc1y%joerg.schill...@fokus.fraunhofer.de> | But you forgot that after this variable content is expanded, it is quoted in a | way to

Re: Pushing/restoring a file descriptor for a compound command

Date:Sat, 28 Apr 2018 00:23:51 +0200 From:Martijn Dekker Message-ID: <8800d6d5-67ea-fad4-19c3-dac4bbfd8...@inlv.org> | That said, do you have any opinion on whether something like | { ... ; } 3>&- | should push/restore a closed file

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

Date:Fri, 27 Apr 2018 10:00:50 +0100 From:Geoff Clare Message-ID: <20180427090050.GA2538@lt2.masqnet> quoting me: | > 4. On the question of bug 985 ... (kind of related) - if quote removal is | > added to case pattern processing, it makes

Re: Laundry list

Date:Thu, 26 Apr 2018 11:56:09 +0200 From:Joerg Schilling Message-ID: <5ae1a239.3rdvpcuahhnmbtgl%joerg.schill...@fokus.fraunhofer.de> | > A4. Option flag 'i' in $- to see if shell is interactive. | The flag "i" has a

Re: Pushing/restoring a file descriptor for a compound command

Date:Sat, 28 Apr 2018 03:53:12 +0200 From:Martijn Dekker Message-ID: <81b93245-e42f-ad62-4005-8ad676733...@inlv.org> | How does NetBSD sh handle this? This isn't really the best place for code samples, but ... "fd" is the file descriptor in

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

Date:Tue, 15 May 2018 18:42:29 -0400 From:Shware Systems Message-ID: <16365f81e7e-179a-29...@webjas-vab019.srv.aolmail.net> | That locale would define a latindigs charclass, same as Venusians are requi= | red to define a vdigits for theirs,

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

Date:Tue, 15 May 2018 13:38:15 -0500 From:Eric Blake Message-ID: <08af8b99-dcf0-5775-3aed-533611cec...@redhat.com> | Please read http://austingroupbugs.net/view.php?id=1078 where this | wording has been tightened to cover ALL locales, not just

Re: Laundry list

Date:Thu, 26 Apr 2018 15:42:11 +0200 From:Joerg Schilling Message-ID: <5ae1d733.R5TWM/czxzjsra9r%joerg.schill...@fokus.fraunhofer.de> | mkdir() has been introduced in order to overcome a security problem. Yes, that's one of the

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

1. There is text dealing with backslash processing at 2 separate places in 2.13.1. First at lines 76212-3 A character shall escape the following character. The escaping shall be discarded. and then at lines 76232-8 (which is on the following page) When pattern

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

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? Is this absolutely the same as echo a*"?" ? And

Re: [1003.1(2016)/Issue7+TC2 0001154]: Add 'rm -v'

Date:Thu, 26 Oct 2017 22:37:09 +0100 From:Stephane Chazelas Message-ID: <20171026213709.jhhuoso6d2v7c...@chaz.gmail.com> | I'd let native English speaker come up with a better wording. I don't think this as as much of who or what

Contacting NetBSD for standards related matters

After the late November basename/dirname change issue (bug 1064), where the way to get info to NetBSD was seen as to contact me (which worked in this case, but is not necessarily long term the most reliable of methods) NetBSD has created a new e-mail address: standa...@netbsd.org for use

Re: [1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions

For anyone who follows this stuff from the mailing list messages, rather than viewing the issues web page, note that I made 3 small edits to note 4070 as it was sent to the list (all inconsequentially really, but...) Two of them were to fix the range of line numbers in the third last line of the

Re: [1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions

Date:Fri, 10 Aug 2018 16:48:29 +0100 From:Geoff Clare Message-ID: <20180810154829.GA26874@lt2.masqnet> | Wouldn't simply changing | "multiple fields" to "multiple fields or no fields" solve it? I am sure there are many ways it could be solved. That is one, if

Re: [1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions

Date:Fri, 10 Aug 2018 16:48:29 +0100 From:Geoff Clare Message-ID: <20180810154829.GA26874@lt2.masqnet> | Wouldn't simply changing | "multiple fields" to "multiple fields or no fields" solve it? There was one more thing I meant to say about that solution, which

Re: [1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions

Date:Fri, 10 Aug 2018 14:33:37 +0100 From:Geoff Clare Message-ID: <2018081017.GA24957@lt2.masqnet> | I don't see the need to have an intermediate fix in 1123; it will just | create extra work to edit both bugs. They will both go into the next | update to

Re: [1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions

Date:Fri, 10 Aug 2018 13:30:28 +0100 From:Geoff Clare Message-ID: <20180810123028.GA23963@lt2.masqnet> | Actually, I think the existing description of Field Splitting handles | it correctly. I disagree, but not for the reason that I think you believe... | It

Re: [1003.1(2013)/Issue7+TC1 0001123]: Problematic specification of execution environment for word expansions

Date:Fri, 10 Aug 2018 16:26:13 +0100 From:Geoff Clare Message-ID: <20180810152613.GA26492@lt2.masqnet> | Brace expansion is widely implemented, so the chance it will be rejected | is zero. I agree that something needs to be done, but it might not be 1193. To me

Re: line continuation (was: sed -e 'a\' -e text)

However you remember any discussions, it has never been the case in any version of the Bourne Shell that a \ inside a '' (single quoted) string means anything at all - ever. It is simply a character like any other (except the closing single quote, and \0). Coming just before a newline makes no

  1   2   3   4   5   6   7   >