It seems ast-developers is still supposed to be the main bug reporting
list, but reaching the associated machine spotty, as to when that server is
booted up. A monitored bug fixes/new features fork probably won't be
maintained until David gets his own copy of the repo, or if he wants push
There is no precise definition of "acceptable", effectively. It's tied
into the requirements specific processors
or platforms have on where code and data can be placed in memory, which is
outside C's and POSIX's
scope. Most systems elect to localize all the (gory) details of creating
an
I don't see that it requires tracking any closed handle. The effect of
returning non-zero for a valid handle value is more, to me, that the value
stays in any list of open handles and any referenced structure marked
inconsistent, possibly until process exit, possibly until an asynchronous
It appears an Application Usage note that Portable Applications should
mask off EINTR from delivery before calling close(), and reenable delivery
after close() returns, is warranted for predictable behavior. This would give
implementations a chance to do additional cleanup before the
I agree something along these lines should be added. As worded now the
assumption looks to be more the system is a single user one, or sandboxed to
that effect, not a multi-user server. It doesn't even have to be a different
user; a separate process that happens to use the same tmpnam()
Some older shells don't do longest match tokenizing of operators, so they
might construe
++a as +(+a) or --a as -(-a). I suspect that is how dash and ksh88 are
actually evaluating
them, not ignoring them silently. With some hardware -(-a) isn't a no-op;
it forces a format
normalization.
Just so people know, most of those comments on the etherpad aren't mine. I
get the margin credit on the page because I pasted it from last week's
notes as reference, as I'm who usually sets up the agenda boilerplate each
week. If I'm running late, someone else that knows how to do it does it
The grammar has 'program' now too, so it doesn't necessarily follow that a
script is precluded, I'd think... The exec() would be again of a shell
instance, or equivalent. The wording has been, to me, more "replace with what
is specified by simple_command as operand", whether that is a
Only the explicit assignment preceding the command_word is evaluated in the
new context, and uses the value from the caller's context temporarily. The
expansions all occur in, and assignments affect, the caller's context
first. So I agree VAR should stay an empty string or unset, but M, N,
By P2366, L75534, redirections are performed in a subshell when no command
name results, such as one affecting an entire compound command... It goes
on that redirections otherwise may fail as part of the current execution
environment, not the pending command environment. Maybe it needs to be
I disagree about $M, as I see those sub-bullets applying during evaluation
of that command or assignments only, in that order of evaluation isn't
guaranteed except as a consequence of expansion nesting, and so a reference
may get either a pre- or post-assignment value; but by the definition
This is my take on the discussion so far:
As the method of forcing an environment to be POSIX conforming is
implementation-defined in XBD 2, this method should be part of the conformance
questionnaire, for both booting into this environment before the interactive
shell starts, for
I agree this aspect could be clearer, in that they aren't a breaking error,
simply superfluous. The general behavior presently is to ignore back
references in replacement strings with EREs as match strings, substituting the
empty string, that I see, same as if \9 specified for a BRE that has
Yes, reception can be blocked for reasons outside a scripts control before
an action is set with trap, but the standard does speak to when signals are
to be raised and delivery attempted. There is no blanket exception I see,
if a regular utility is implemented as a built-in, that the system
Still, the effects on the environment should be the same, as separate
utility or built-in, including signal generation... Exceptions are for the
special built-ins the standard requires be part of the shell, when documented
that way, that I see.
In a message dated 5/10/2017 7:45:32 A.M.
Once the action is set, delivery should succeed, imo, for each child that
would normally have a separate process id due to creation of a child
utility environment. I can see older Unix's that didn't track process ids in
sigevent structures, because they only implemented signal() and
I'm wondering, is it desirable to have a precedence of checking list, since
'#' can be either parameter name or operator in that context, or require
if there is ambiguity that the # special parameter be represented as $#
inside the braces? I'm thinking 'foo=$# ${#foo##pat}' and '${pat}'
This would be the XRAT volume, and Change History in individual entries...
This is only exhaustive in coverage from when the POSIX Group was formed,
it appears, not for earlier IEEE and OpenGroup versions. There is a table
of when various interfaces became part of the standard that A.Josey
I thought we touched upon this also in discussing adding $'...', with the
resolution the arguments were WORDs in the grammatical sense and to be
scanned that way with regards to quoting. This would supercede that clause in
221, as the standard choosing between conflicting interpretations
The expected behavior is nothing gets written, since the size_t n argument
is 0. Whether *() gets written to or not is ambiguous. The implied
behavior is that since it is only checking what the buffer length should be, by
the paragraph at line 31022, any %n is ignored since no output is
That's why it's spelled out, so people don't use the Unicode visual
duplicate in most fonts if some engine substitutes it, as Mantis does
sometimes.
Probably because '/' missing from following tag closure.
In a message dated 5/26/2017 11:12:17 A.M. Eastern Daylight Time,
I believe the purpose of this relates to when the -o option is specified
it provides a way to use the no operand form to list values set from the
environment at startup, so sh -o - ; or sh -o ; behaves like set -o ; but
still permits something like
sh -co - verbose -- arg1 ;
to treat
I'm not against, as long as it doesn't reopen the trapdoor issue, but
think it would have to be explicit the option listing function, -o or +o
without
value, is not supported by sh, just set; including 'sh -o;' and 'sh +o;'
forms to keep it simple. This addresses the ambiguity that -o
I don't see the interface invoked to block the thread is allowed to cancel
the request completely, simply that the interface may return to reduce
serialization latencies for the 2 bullet point cases and the cancellation
honored at the next plausible point in the code path, in accordance with
In a message dated 6/10/2017 10:16:54 A.M. Eastern Daylight Time,
nore...@msnkbrown.net writes:
(it's not even clear if such arrays of bytes may be stored in
shell variables).
This is allowed, clearly, but you currently have to jump through hoops to
make use of an arbitrary sequence when
Sorry for the confusion, I was looking at some code recently that appears
to initialize a new file description with independent seek pointer from an
open handle as part of what they call a dup(). It does save having to track
the path string so open(path, ...) doesn't have to be used
Ty Joe, that will be useful.
In a message dated 6/15/2017 4:44:49 P.M. Eastern Daylight Time,
gw...@raytheon.com writes:
Joe M.
I asked the IEEE if they could provide 1003.1b-1993 to The Austin Group,
to support the revision of 1003.1-2008, and the IEEE have provided
1003.1b-1993
The thing is, various shells have implemented time as keyword, so this bug is
trying to get the standard to reflect actual practice that ignored that
Rationale. The debate is more some things allowed to utilities aren't allowed
for keywords, and vice versa, so there are advantages to both.
As
compatibility or needing any new keywords.
On Tuesday, February 25, 2020 Robert Elz wrote:
Date: Tue, 25 Feb 2020 17:47:23 + (UTC)
From: shwaresyst
Message-ID: <1701159045.321204.1582652843...@mail.yahoo.com>
| The thing is, various shells have implemente
The parentheses are there to indicate all those are interfaces, without the
wordier "last msgsnd interface call", or similar, in those lines.
On Sunday, February 23, 2020 Austin Group Bug Tracker
wrote:
The following issue has been SUBMITTED.
I disagree with the notion of using names with colons, especially for new
utilities, mainly because colon is the character used as path separator in PATH
and there may be usage ambiguities resulting from this overload. I'd be more in
favor of implementing labels with another character entirely
If you're going to go with 'z' suffix, "statz" is an option too; for
session/process statistics or "state of the machine".
On Monday, February 24, 2020 Scott Lurndal wrote:
On Mon, Feb 24, 2020 at 09:23:16AM +, Geoff Clare wrote:
> Chet Ramey wrote, on 16 Feb 2020:
> >
> > On 2/15/20 9:42
Presently, no. There are operations, such as with semaphores, where this sort
of functionality might be used but has been left unspecified as many CPUs don't
support exchanges; for most older ones only loads and stores are atomic, and
the volatile modifier and sigatomic_t types are geared to
al Message-
From: Robert Elz
To: shwaresyst
Cc: Joerg.Schilling ; gwc
; austin-group-l
Sent: Tue, Feb 18, 2020 11:34 AM
Subject: Re: [1003.1(2004)/Issue 6 267]: time (keyword)
Date:Tue, 18 Feb 2020 15:26:43 + (UTC)From:
shwaresyst
ly storing the definition, and
confusing the user, are more the conforming behavior.
-Original Message-
From: Joerg Schilling
To: shwaresyst ; kre
Cc: gwc ; austin-group-l
Sent: Tue, Feb 18, 2020 12:08 PM
Subject: Re: Re: [1003.1(2004)/Issue 6 267]: time (keyword)
shwaresyst wrote:&g
It shouldn't matter whether a token prefix matches a reserved word or not;
because the lparen is not separated by a function definition should be
the "best, longest" match production that it is interpreted as, and so wouldn't
be a syntax error. It's on use that keyword recognition would hide
Fyi, the Last updated: date at top wasn't changed.
On Thursday, March 12, 2020 Austin Group Bug Tracker
wrote:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=411
Yw... Also, while change is minor, just putting out for next meeting, we
probably want to take a look at the Related: bugs with Interpretations, see if
any those need a timer restart to reflect the change properly.
On Thursday, March 12, 2020 Eric Blake wrote:
On 3/12/20 1:02 PM, shwaresyst
I basically agree this is an issue - I see return as more for being interpreted
as a lexical scope abort, whatever the execution context, and exit an execution
scope abort, such as a subshell or separate script utility environment, as
their basic intent. Further complicating things, I don't
I agree this is something suitable for a TC type resolution. However, given the
amount of existing practice, I do not see we should leave anything unspecified
for Issue 8, even if some implementations break as a result.
Either it always stops function execution or dot file processing, which
yes, it is being worked on but not as a high priority, so Option 2 appears to
be a no go. It may be better to revisit the bug and add a test for its
availability to sysconf()/getconf as a formal option, in a Coming Attractions
sense, so code can be written portably now based on using Option 1
It seems to me that what is missing, in XCU 2.3.1, is a statement that use of
keywords in alias bodies is unspecified behavior.
Even outside double quotes an initial scan collecting tokens to form a logical
line distinct from a potential io-here body will have to treat an alias name as
a
: Mon, 20 Apr 2020 21:17:12 + (UTC)
From: shwaresyst
Message-ID: <1050536090.3716059.1587417432...@mail.yahoo.com>
| No, those are attempts at speed optimizations;
I'm sad to have to reply like this, but do you have any idea at all
what you're talking
an actual name until recognition of the line as a whole has been
completed.
On Monday, April 20, 2020 Robert Elz wrote:
Date: Mon, 20 Apr 2020 18:01:49 + (UTC)
From: shwaresyst
Message-ID: <1837359500.1041757.1587405709...@mail.yahoo.com>
| It seems to me tha
impossible to have an interpreter that expands
alias bodies first, simply that sh does not do it that way due to the possible
ambiguities.
On Tuesday, April 21, 2020 Joerg Schilling
wrote:
shwaresyst wrote:
> No, those are attempts at speed optimizations; the description before the
> numb
The wording can be construed the intent is the EXIT trap is always expected to
be called, with a SIGEXIT delivered to the context of the subshell and not the
parent, and otherwise to the parent for performing the trap in its context and
terminating the parent. While a subshell context is
This is not a duplicate, bug 315 covers only one case, this points out it
applies to other places. If anything it is a child, not duplicate, that's why
it was Accepted.
On Thursday, April 2, 2020 Austin Group Bug Tracker
wrote:
The following issue has been set as DUPLICATE OF issue 315.
The GNU version is more correct, in my opinion, in that the use of n as a
delimiter should take precedence over its use as control character alias with
the wording as is. The other versions appear to consider the BRE as
so does not match 'n'.
On Wednesday, March 25, 2020 Oğuz wrote:
echo
delimeter overrides that interpretation, to
get the results observed.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 21:09, shwaresyst wrote:
> If it wasn't in single quotes, then that might be plausible, but I don't
> see it as the intent since no other aliases are excluded as
delimeter overrides that interpretation, to
get the results observed.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 21:09, shwaresyst wrote:
> If it wasn't in single quotes, then that might be plausible, but I don't
> see it as the intent since no other aliases are excluded as
llowing 'n' is the terminator, before the
'd' command. Should there be something explicit about aliases not being usable
when repurposed as delimiter, maybe.
On Wednesday, March 25, 2020 Harald van Dijk wrote:
On 25/03/2020 19:44, shwaresyst wrote:
> The GNU version is more correct, in my opinion, in that
This has been suggested, but the ORs feel the time for such is when Issue 8 is
formally released, not before. The austin-futures-l list is more the intended
vehicle for issues of that nature, as to what's in place already, but it does
not have its own Mantis, or other browser based, interface.
Um, I did not say that people should get a draft whenever they want one, simply
that the other list is being underutilized for discussion of issues arising
from Mantis, not any drafts, until we have a release we feel is ready for
public review. I wholly agree trying to reference non-releases
ce.
On Thursday, April 2, 2020 Geoff Clare wrote:
shwaresyst wrote, on 02 Apr 2020:
>
> This is not a duplicate, bug 315 covers only one case, this points out it
> applies to other places. If anything it is a child, not duplicate, that's why
> it was Accepted.
It was
Dijk wrote:
On 25/03/2020 23:30, shwaresyst wrote:
> yes, without them the argument would be "nnnd", after quote removal by
> the shell. The reasoning in first reply was meant to show that the
> non-GNU versions might be erroneously treating the second '\' as "do
> con
, to
indicate end of pattern, not ')', but these don't become part of the base PCS
until Issue 9.
On Wednesday, April 22, 2020 Joerg Schilling
wrote:
shwaresyst wrote:
> No, you only lex up to the newline or EOF in the first pass, whether the
> ending ')' or other context delimeter is
for first lexically, then you'd have a stronger case, but it never has
that I've seen.
On Wednesday, April 22, 2020 Joerg Schilling
wrote:
shwaresyst wrote:
> When you are evaluating substitutions, yes, expansion is required, but not on
> the first pass recognizing them. This is the
Robert Elz wrote:
Date: Sat, 9 May 2020 13:00:54 + (UTC)
From: shwaresyst
Message-ID: <600759678.614717.1589029254...@mail.yahoo.com>
| Just floating this out there... While a posix_spawnp() kernel imp doing
| PATH searches relative to the parent's pwd is
Personally, the offer is appreciated, but I would not find scans of the
documents wrapped as a pdf all that useful, if this is intent. Using the
original troff, if this is still available, to generate copy and searchable
versions, with TOC and xrefs, would be nicer.
On Monday, May 18, 2020 J
Just floating this out there... While a posix_spawnp() kernel imp doing PATH
searches relative to the parent's pwd is a well defined behavior, should there
be an additional file_action that search for the executable happens after the
chdir action; for the case where PATH, as inherited by the
I can't reopen the bug to add a note, so like we did 1318 on top of 411, it
probably should be reopened and discussed. Straightforward or not, what you put
in is not what is marked as to be put in.
On Thursday, March 19, 2020 Geoff Clare wrote:
shwaresyst wrote, on 18 Mar 2020
se wrote:
On 10/03/20 18:25, shwaresyst wrote:
>
> I basically agree this is an issue - I see return as more for being
interpreted as a lexical scope abort, whatever the execution context,
and exit an execution scope abort, such as a subshell or separate script
utility environment, as their
Re: matter in connection with
C's stderr but only for file descriptor 2 (as inherited by the login
shell).
Isn't there something about stdin, stdout, and stderr being required to
reference the same open file descriptions as fd's 0, 1, and 2, respectively,
with inheritance? An application can
No, I did have the "respectively" in there, for 3 separate possible file
descriptions. It is also, near as I can tell, a requirement of the C standard
those FILE records exist and be usable at program startup, whether
included or not, for referencing either an already open stream or be in a
t;, and by extension "POSIX",
locale is unchanged from C99, and has not added %Z. This would apply to its
usage both by strftime() and strptime(), to maintain symmetry, I would think.
On Tuesday, July 21, 2020 J William Piggott wrote:
On Sun, 12 Jul 2020, shwaresyst wrote:
Thank y
Also, as something new, its inclusion is part of a later draft of Issue 8.
Additional issues it depends on need to be addressed first, specified fully,
and incorporated. This is more why it went on the back burner, that I recall.
Various other bugs are in similar state; the prerequisites to
Robert has a point that assignments, as represented by the ASSIGNMENT_WORD
token in the grammar, should be represented by a production of the form:
ASSIGNMENT_WORD :: name EQ WORD
For 2.6.1 that is the assignment form referenced where word expansion, of the
WORD in that production, is relevant
conversions are
plausible, it's just how has no portable specification currently, it is left as
unspecified.
On Friday, July 31, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<1371185781.9853799.1596158030...@mail.yahoo.com>:
|It is not "some sensible \u sequences" alone. First off
That still has some_other_command never getting executed, so I think just
adding the printf sufficient.
On Wednesday, July 8, 2020 Nick Stoughton wrote:
The whole point of this example is to show that the exit status *of the while
loop* will be zero if the loop does not execute, and if you
The necessity for "0x" is to disambiguate from octal numbers with their leading
'0', or decimal for a context allowing leading zeroes, but since a 0 is the
same in all radices I suspect the decision was not to require it to keep field
width minimal for delimited formats like CSV.
As to 2nd,
The reason for the disconnect, that I see, is because the %Z modifier
references the TZ environment variable, not a value in a struct tm, adding it
to d_t_fmt would disqualify the definition from being __STD_C__ conforming.
This is one of the areas where the C standard can be considered
There are plans for this, having a POSIX.UTF-8 locale as an XSI base
requirement. There may be POSIX.UTF-E and UTF-I locales too; same features,
simply the different charmaps. As options there may even be, albeit this is
unlikely as no platform I'm aware of fully supports ISO-6429 now, a
The locale requirements specified in the C standard are what is applicable for
implementations that limit their character encoding to the basic source and
execution character sets. POSIX requires implementations to support, in at
least one provided charmap, the superset of the basic sets
The command alias is nominally conforming, I believe, in that recursive alias
expansion isn't permitted so looking for a utility named command still occurs.
However, the implementation of various utilities as aliases changes the
reporting of 'command -v', or '-V', to that they are aliases and
Re: Are not the examples demonstrating relevant date utility specification
requirments as follows:
No, they are examples of how the various specified elements can produce output
reflecting various locale LC_TIME settings, that's all. The actual format
string is still an unspecified
There is also the POSIX locale is a superset of the C locale as defined by the
C standard, because it requires support of the Portable Character Set, which
has more chars than C requires, and has the LC_MESSAGES category; as primary
differences.
On Wednesday, June 10, 2020 Joerg Schilling
That the semantics are unspecified already disqualifies them from use by
portable applications. If it was implementation-defined then such an addition
might be warranted, that I see.
On Saturday, July 25, 2020 Danny Niu wrote:
RFC 6093 "On the Implementation of the TCP Urgent Mechanism"
That reference was left as-is because the Issue 8 draft targets C17 (or 18),
but there's a chance c2x may get ratified first so that may affect later drafts.
On Sunday, July 19, 2020 Quentin Rameau wrote:
Hello,
> ==
>
understand left-associative combining
sequences, and these interfaces are portable because requirements in XBD add
that support.
On Thursday, July 30, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<1127836834.9524758.1596121054...@mail.yahoo.com>:
|Yes, the additions necessary still
to
be written, or published if some have been.
On Thursday, July 30, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<311169368.9432836.1596108598...@mail.yahoo.com>:
|On Thursday, July 30, 2020 Geoff Clare wrote:
|Robert Elz wrote, on 29 Jul 2020:
|>
|> Speaking of
needs to be
implemented to be wrapped.
On Tuesday, September 1, 2020 Steffen Nurpmeso wrote:
shwaresyst wrote in
<1739483391.1543785.1598977118...@mail.yahoo.com>:
|No, it couldn't introduce such a macro, because such would have to \
|assume all d_name entries are the same length.
array is not a VLA, in the sense C uses the term.
From: shwaresyst
Sent: September 1, 2020 4:55 PM
To: Wojtek Lerch ; austin-group-l@opengroup.org
Subject: RE: [1003.1(2013)/Issue7+TC1 697]: Adding of a getdirentries()
function
What that refers to, it looks, is any tail padding
d to page-align data structures in some
situations, I still don’t see its relevance to a discussion of the C standard’s
requirements regarding padding in struct types and how it’s affected by
flexible arrays.
From: shwaresyst
Sent: September 2, 2020 1:58 PM
To: Wojtek Lerch ; austin-g
No, it couldn't introduce such a macro, because such would have to assume all
d_name entries are the same length. Adding an option to the interface to do a
count, as a vararg parameter, and directly malloc the necessary space, returned
via my suggested change to buf as a **, is plausible.
I agree some additional clarity might be useful there, in the C standard. I'm
reading it as the intent being sizeof is equivalent to offsetof the VLA in
accordance with the restrictions placed on it by use of the . or -> operators,
which may not need extra bytes (so >vla == ( + sizeof(s)) is a
. Furthermore,
requiring these existing implementations to change their layout would break
binary backwards compatibility with previous versions.
See DR282 for more
details:http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_282.htm
From: shwaresyst
Sent: September 1, 2020 2:27 PM
The C standard leaves it undefined for fread() because it doesn't require
EOVERFLOW in , that I see, or presumes size_t will always be a short
or int type. Since POSIX does have it and does not presume a limited width I
feel this is a place where a CX extension is warranted as a portability
Once pthread_attr_init() successfully completes the guardsize should be set to
the default value and may be examined by pthread_attr_getguardsize(), that I
see. A call to setguardsize() should store the value and be returned by
subsequent getguardsize() calls, even though it is not used after
a
pointer to the attr object.
On Tuesday, September 22, 2020 Robert Elz wrote:
Date: Tue, 22 Sep 2020 11:05:05 + (UTC)
From: "shwaresyst via austin-group-l at The Open Group"
Message-ID: <1248402378.5117076.1600772705...@mail.yahoo.com>
| Once p
by the application.
On Tuesday, September 22, 2020 Robert Elz wrote:
Date: Tue, 22 Sep 2020 14:38:07 + (UTC)
From: shwaresyst
Message-ID: <32911555.5186984.1600785487...@mail.yahoo.com>
| Yes, it is no longer a factor,
I would have guessed that is what "not
The 2018 edition is the latest ISO/IEC/IEEE version, in that it was balloted
and approved to keep the IEEE "current standard" clock from timing out. The
2008 edition plus TCs is now the prior version, in the formal sense.
On Thursday, September 24, 2020 Jonathan Wakely via austin-group-l at The
It's my understanding ISO/IEC was to bump their distribution also, to keep in
synch. Nick S. would be more conversant with the details of thay, though.
On Monday, September 28, 2020 Jonathan Wakely wrote:
On 28/09/20 14:36 +, shwaresyst wrote:
>
>The 2018 edition is the latest ISO/IE
As I read it, file size and *seek(SEEK_END, 0) will still be 16, reflecting how
many bytes were written to the buffer and which had to be malloc'd. The rewind
overwrites the first bytes and a flush, close reflects the size of data
considered to be valid after the rewind, since there is no
The text relevant to all this I see is the paragraph at line 104150, page 3114,
c181.pdf, which limits outputs to the internal representation range of the
format characters used, converted back to text. This should probably be
explicit that the conversion shall detect overflows, positive or
t as an actual value.
On Saturday, October 24, 2020 Robert Elz wrote:
Date: Sat, 24 Oct 2020 16:47:41 + (UTC)
From: shwaresyst
Message-ID: <160402159.2963847.1603558061...@mail.yahoo.com>
| The text relevant to all this I see is the paragraph at line 104150,
The slave side is ancillary to the master, sorry, as physical terminals are
ancillary to the processor hardware, imo. Inverting the relationship makes it
look like it is the intent of the slave side to source the majority of the
data, when more often it is only monitoring output data sourced
versions of the standard with one runtime and set of headers.
On Thursday, December 3, 2020 Robert Elz wrote:
Date: Thu, 3 Dec 2020 18:11:51 + (UTC)
From: shwaresyst
Message-ID: <684426419.4103424.1607019111...@mail.yahoo.com>
| The 20yymmL shall be replaced with the
The 20yymmL shall be replaced with the value specific to Issue 8 when that is
finalized, not that an implementation may choose an arbitrary value after 2000.
It's a placeholder to indicate this for the bug report only. The other 200809L
values all get a blanket change eventually too,
I agree more clarification is desirable. The reason I see as why the function
isn't executed is it may be treating it as an invoke of "sh -c ls", because ls
is a function, but this new sh does not inherit that definition so it looks on
path instead and finds the utility.
On Wednesday, December
, November 3, 2020 Paul Smith via austin-group-l at The Open Group
wrote:
On Mon, 2020-11-02 at 15:44 +, shwaresyst via austin-group-l at The
Open Group wrote:
> With that phrasing is also reserved, since it
> is not " followed ONLY by uppercase". Using ".NO_parallel"
>
1 - 100 of 121 matches
Mail list logo
