30 Haziran 2021 Çarşamba tarihinde L A Walsh via austin-group-l at The Open
Group yazdı:
>
> Anyway, it is the parent that is directed the output to a location that
> won't work as an output destination. In my example with >/dev/zero, I
> got a permission denied from the parent process. If I had
On 2021/06/29 17:55, Vincent Lefevre wrote:
On 2021-06-29 13:30:53 -0700, L A Walsh wrote:
---
No. the pwd utility has had its stdout redirected by its
parent, "the shell". Since the faulty redirection was done by parent,
is the error in the child or the parent?
The redirection is
On 2021-06-30 00:46:00 +, mirabilos via austin-group-l at The Open Group
wrote:
> Using the same shorthand, I changed mksh tonight to do pretty much
> what you described, in a second patch:
>
> @@ pseudo @@
> int
> call_builtin(func_t builtinfunc, int argc, char *argv[])
> {
> int exi
Vincent Lefevre via austin-group-l at The Open Group dixit:
> an EPIPE error; only in this case, this diagnostic message may be
> annoying because the EPIPE error is an expected error (though it
Yeah, this is going to be annoying.
>where close_stdout check any error on stdout and stderr.
>No
Don Cragun dixit:
>No.
[…]
Erm, yes. For some reason, I assumed the OP wrote &> instead of >&
which have the same meaning in GNU bash (but &> is the parse-trouble
one even if the bash manpage actively recommends it). I guess their
“~>&” confused me. My point of _please_ using “>file 2>&1” instead
On 2021-06-29 13:30:53 -0700, L A Walsh wrote:
> On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open Group
> wrote:
> > Don Cragun via austin-group-l at The Open Group dixit:
> >
> > > • When an unrecoverable error condition is
> > > encountered, the utility shall exit with
Robert Elz via austin-group-l at The Open Group dixit:
> | > You might prefer that it "fflush(stdout); if (ferror(stdout)) ..." but
> | > there's nothing explicit in the standard that says that it has to do
> that.
>There was no argument based upon C functions - the use of them was
>just a sho
On 2021-06-29 17:28:40 +0100, Stephane Chazelas via austin-group-l at The Open
Group wrote:
> 2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open
> Group:
> [...]
> > > (
> > > sleep 1
> > > set +o errexit -o xtrace
> > > pwd
> > > pwd
> > > ) | :
> > >
> > > Calls
On 2021-06-29 22:43:49 +0700, Robert Elz via austin-group-l at The Open Group
wrote:
> Date:Tue, 29 Jun 2021 09:49:40 +0100
> From:"Geoff Clare via austin-group-l at The Open Group"
>
> Message-ID: <20210629084940.GA8391@localhost>
>
> | You are wrong when you say
> On Jun 29, 2021, at 3:20 PM, tg...@mirbsd.org via austin-group-l at The Open
> Group wrote:
>
>> ... ... ...
>
> Ah, so you meant…
>
>> "/tmp cd ~ >& /dev/zero"
>
> … which was not clear from the punctuation salad you posted.
>
>> "Violates POSIX on the parse level?!" Eek! Next
>
> It
On 2021/06/29 15:20, tg...@mirbsd.org wrote:
"/tmp cd ~ >& /dev/zero"
cd ~>& is parsed correctly in more "intelligent" parsers.
"Violates POSIX on the parse level?!" Eek! Next
It does: >& is parsed as > & by POSIX rules, TTBOMK.
---
"What? WHAT?" Your abbreviation is
L A Walsh dixit:
>> What? WHAT?
>>
>> Could you please translate that to proper sh syntax?
>> I know the GNU bash extension >& (which incidentally
>> violates POSIX on the parse level) but not ~>&…
>>
> POSIX doesn't allow 'cd ~' to change to your home
Ah, so you meant…
> "/tmp cd ~ >& /dev/ze
On 2021/06/29 14:09, tg...@mirbsd.org wrote:
L A Walsh via austin-group-l at The Open Group dixit:
along those lines:
/tmp pwd >& /dev/zero
-bash: /dev/zero: Permission denied
/tmp> echo $?
1
/tmp> cd ~>& /dev/zero #note the command isn't executed
-bash: /dev/zero: Permis
L A Walsh via austin-group-l at The Open Group dixit:
> along those lines:
>
> /tmp pwd >& /dev/zero
> -bash: /dev/zero: Permission denied
> /tmp> echo $?
> 1
> /tmp> cd ~>& /dev/zero #note the command isn't executed
> -bash: /dev/zero: Permission denied
> /tmp>
What? WHAT?
Co
On 2021/06/29 13:30, L A Walsh via austin-group-l at The Open Group wrote:
On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open
Group wrote:
Is “pwd >/dev/full” an “unrecoverable error condition” as regards
the pwd utility?
---
No. the pwd utility has had its stdout redir
On 2021/06/27 14:33, tg...@mirbsd.org via austin-group-l at The Open
Group wrote:
Don Cragun via austin-group-l at The Open Group dixit:
• When an unrecoverable error condition is
encountered, the utility shall exit with a
non-zero exit status.
Is “pwd >/de
Date:Tue, 29 Jun 2021 01:52:32 +0200
From:Vincent Lefevre
Message-ID: <20210628235232.gb46...@zira.vinc17.org>
| Where is this written (at least for the particular case of builtins)?
Philip Guenther supplied the text - there's nothing special about
builtins (logica
2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open Group:
[...]
> > (
> > sleep 1
> > set +o errexit -o xtrace
> > pwd
> > pwd
> > ) | :
> >
> > Calls pwd only once with most shell implementations (all those
> > where pwd is builtin).
> >
> > Is that allowed?
>
> S
Date:Tue, 29 Jun 2021 09:49:40 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210629084940.GA8391@localhost>
| You are wrong when you say it "printed it". It tried to print it but
| failed to do so.
But how do you actually know? I
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YE
On 2021-06-29 14:11:45 +0100, Stephane Chazelas via austin-group-l at The Open
Group wrote:
> 2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group:
> [...]
> > > If in general, then forget it - the users would lynch you (you'd probably
> > > suicide first) if you successfull
2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group:
[...]
> > If in general, then forget it - the users would lynch you (you'd probably
> > suicide first) if you successfully caused that to happen.
>
> No they wouldn't. The only reason to set SIGPIPE to be ignored is
> be
tg...@mirbsd.org wrote, on 28 Jun 2021:
>
> Stephane Chazelas via austin-group-l at The Open Group dixit:
>
> >2021-06-28 20:01:03 +0700, Robert Elz:
> >[...]
>
> I see significant support here for my interpretation of this.
I suspect it is a vocal minority, and the vast majority of members
of t
Robert Elz wrote, on 28 Jun 2021:
>
> austin-group-l@opengroup.org (really Geoff Clare) said:
> | The error occurred, and because of it the utility did not do what it is
> | supposed to do.
>
> That's debatable. The outcome was not what was desired, but the utility
> did exactly what was req
24 matches
Mail list logo
