@EliahKagan hence the head scratching over why the segfault message isn't suppressed if crash is on the right side of the pipe?

@Zanna When the pipeline is executed by bash, yes.

thinking aloud if the command on the left side had any stdout, it would go into the pipe. If the command on the right side had any output, it would go to the terminal... but the segfault message isn't output from the program and isn't on stdout. It isn't being piped, but the pipe stops it from being written, as if the shell had decided nobody would be there to read it

Go on.

All I have been doing so far with this problem has been thinking aloud. So that is definitely welcome!

well, if the command is on the right side the message is written, as if the shell thinks someone will want to see it. Does the subshell write the message? What's the difference between the first subshell and the second subshell?

when you write a command that has a pipe (or multiple pipes) in it, the shell will set up the pipeline first (before executing any of the programs that you want to call) I think. So, what exactly does that involve? I think I actually read about that somewhere and forgot it (but that applies to far more things than I actually do remember so...)

(Not expecting anyone to answer my questions here)

Yes, the pipeline is established before any redirections, which are themselves established before simple commands are run (which includes forking and execing the processes for them).

The expected way for a shell to create a pipeline is to call pipe once per connection, i.e., each occurrence of the | operator would typically cause pipe to be called to construct the pipe object. The shell passes a pointer to wherever that function should write the two file descriptors associated with the pipe: the one for the read end and the one for the write end.

(In systems that use kernels besides Linux I believe pipes are often technically bidrectional, but you still get two file descriptors, one for each end, from calling pipe.)

Then when it runs the commands, the appropriate ends of the pipes are used as their stdin and/or stdout. In practice my guess is that, when an actual subshell is created for a command in the pipeline--as happens in practice for all but the last one in some shells including ksh93 and zsh, and for all of them in others including bash and, I think, dash--the subshell itself may have them as its standard input and standard output.

the subshell's stdin and stdout are the ends of the pipes... so where is the subshell's stderr sent?

It should go wherever the outer shell's stderr goes.

Because commands run in the subshell inherit their stderr from the subshell.

Using my FIFO (named pipe) created before using mkfifo pipe, and already reading from pipe in the second shell (cat pipe), I ran this in the first shell:

(echo first; echo second >&2; echo third) 2>pipe

The output in the first shell was:

first
third

The output in the second shell was:

second

I should have used foo, bar, and baz instead of first, second, and third to avoid confusion between the words being written and the way I am distinguishing the shells from one another. But hopefully that is adequately clear anyway.

I think first second and third are very clear

the stderr of the subshell went where the stderr of the parent shell was redirected

Well because I said the "first" shell and the "second" shell and those have nothing to do with first, second, and third as shown. It's coincidence that I happened to use commands that printed second to what I call the second terminal.

Also, sorry, I meant the "first terminal" and "second terminal."

I got that, no worries

@Zanna Yes. The redirection was performed first, then the subshell ran.

So, I think what is happening in bash might be that it normally doesn't print segfault messages for commands that crash when run in an explicit subshell such as one created through ( ) grouping, but that when a parenthesized group contains only a single command, bash applies the optimization of not actually spawning a subshell.

No, I'm wrong. Guess disproved:

ek@Io:~/source$ echo $BASHPID
332
ek@Io:~/source$ (echo $BASHPID)
23325

How about this: what if bash doesn't print segfault messages for commands that crash when run in an explicit subshell such as one created through ( ) grouping,, but that when a parenthesized group contains only a single command, the bash subshell applies the optimization of execing that command without forking, just as bash does in other circumstances when it must run only a single command before itself terminating.

So the subshell gets replaced with the command, then there is no subshell anymore, and the parent shell is waiting on the command rather than the subshell because it waited on the subshell that was replaced with the command. The command crashes and the outer shell wakes up to see that the command it had run segfaulted, then prints a segfault message.

Yes. First terminal:

ek@Io:~/source$ (perl -we 'use English; print "@ARGV $PID\n"; sleep 100' "$$" "$BASHPID")
332 23396 23396

Second terminal:

ek@Io:~/source$ ps 332 23396 | cat
  PID TTY      STAT   TIME COMMAND
  332 pts/3    Ss     0:00 -bash
23396 pts/3    S+     0:00 perl -we use English; print "@ARGV $PID\n"; sleep 100 332 23396

This is on 16.04. Can you reproduce this on the release you are running?

zanna@toaster:~$  (perl -we 'use English; print "@ARGV $PID\n"; sleep 100' "$$" "$BASHPID")
3031 3042 3042

zanna@toaster:~$ ps 3031 3042 | cat
  PID TTY      STAT   TIME COMMAND
 3031 pts/5    Ss     0:00 bash
 3042 pts/5    S+     0:00 perl -we use English; print "@ARGV $PID\n"; sleep 100 3031 3042

on 17.10

Same.

But ksh93 doesn't perform the optimization.

ek@Io:~/source$ ksh93
$ (perl -we 'use English; print "@ARGV $PID\n"; sleep 100' "$$" "$BASHPID")
23748  23760

ek@Io:~/source$ ps 23748 23760 | cat
  PID TTY      STAT   TIME COMMAND
23748 pts/3    S      0:00 ksh93
23760 pts/3    S+     0:00 perl -we use English; print "@ARGV $PID\n"; sleep 100 23748

Wait.

What am I thinking?!

Obviously $BASHPID does not work on those shells to tell the real PID of a subshell.

:)

Although...

ek@Io:~/source$ mksh -c 'echo "$BASHPID"'
23941

that's handy

But it's complicated enough that we're testing with four shells. I don't really want to add mksh into the mix. (You can, of course, if you like.) As Gilles also mentions in that post, we can use sh -c 'echo $PPID' from any Bourne-style shell.

we aren't worried about the costliness :)

No, we're not.

But anyway we're running a Perl one-liner so we can just have perl report its parent's process ID.

Wait a minute.

Gilles says:

> $BASHPID can be emulated with the costly but portable sh -c 'echo $PPID'

But that is not actually true.

I don't mean that one is expanding a parameter and the other is writing to stdout, which is sort of the pedantic reply and is not an actual problem with the post.

I mean that:

ek@Io:~/source$ echo $$
332
ek@Io:~/source$ (echo $BASHPID)
24362
ek@Io:~/source$ (sh -c 'echo $PPID')
332
ek@Io:~/source$ (:; sh -c 'echo $PPID')
24385

We can't use sh -c '$PPID' anyway because it would be a separate command run in the subshell, or it would be part of the same command by being used in command substitution, but then that's another subshell.... too complicated for these testing purpose.s

But getppid in the Perl one-liner will exhibit the same problem as (sh -c 'echo $PPID').

Though we should be able to use it to our advantage, too.

ek@Io:~/source$ (perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
332 *332 24445

ek@Io:~/source$ ps 332 24445 | cat
  PID TTY      STAT   TIME COMMAND
  332 pts/3    Ss     0:01 -bash
24445 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 332

I've put a * before perl's parent's PID to help us not confuse it with the second field in the earlier one-liner's output, which did not mean the same thing.

Before, when bash did the optimization, $BASHPID was the PID of the subshell before it execed perl without first forking. Therefore it became the PID of perl.

Now, when bash does the optimization, the return value of the Perl function getppid is the parent PID of perl, so it's not the subshell, due to the optimization, but instead it is the subshell's parent. The optimization has been performed when the return value of getppid in the Perl one-liner is the same as what the subshell expands $$ to.

This is what it looks like when the optimization is not performed:

ek@Io:~/source$ (:; perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
332 *24556 24557

ek@Io:~/source$ ps 332 24556 24557 | cat
  PID TTY      STAT   TIME COMMAND
  332 pts/3    Ss     0:01 -bash
24556 pts/3    S+     0:00 -bash
24557 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 332

@EliahKagan sorry to break the flow, but what happened? Why did we get the parent shell's PID from the third command?

There isn't really a flow. The more thoughts you say here the better, even if they're not (yet) explanations of why I'm trying to figure out. :)

What do you mean by "the third command," though?

zanna@toaster:~$ echo $$
3310
zanna@toaster:~$ (sh -c 'echo $PPID')
3310

the second one there ^

we were expecting the same output as with (echo $BASHPID), the PID of the subshell

Oh. Because the optimization is performed in the subshell. The subshell only has one command to run, so it replaces itself with the sh command it is running -- it skips forking and just calls exec. Therefore the sh subprocess of the subshell has the same process ID as the subshell, because it is what the subshell process has become, and its parent is the parent of the subshell, i.e., the outer shell.

I thought Dash doesn't do that

As far as I know, it doesn't.

The subshell is bash, though, and it's the subshell that's replacing itself with sh.

oh, the subshell does it

lol

sorry

it makes perfect sense now

No problem!

Okay, so now with zsh:

ek@Io:~/source$ zsh
Io% (perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
24677 *24677 24684

ek@Io:~/source$ ps 24677 24677 24684 | cat
  PID TTY      STAT   TIME COMMAND
24677 pts/3    S      0:00 zsh
24684 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 24677

Io% (:; perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
24677 *24677 24714

ek@Io:~/source$ ps 24677 24677 24714 | cat
  PID TTY      STAT   TIME COMMAND
24677 pts/3    S      0:00 zsh
24714 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 24677

Io% (perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$"; :)
24677 *24724 24725

ek@Io:~/source$ ps 24677 24724 24725 | cat
  PID TTY      STAT   TIME COMMAND
24677 pts/3    S      0:00 zsh
24724 pts/3    S+     0:00 zsh
24725 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 24677

So this confirms that, unlike bash, zsh performs the optimization for the last command in the list of commands run in the subshell, even when the list has more than one command in it.

@EliahKagan ah like we observed yesterday

Yes.

and ksh93 does the same thing

Can you show? (You need not do so if it's inconvenient.)

zanna@toaster:~$ ksh93
$ (:; perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
3395 *3395 3397

zanna@toaster:~$ ps 3395 3397 | cat
  PID TTY      STAT   TIME COMMAND
 3395 pts/8    S      0:00 ksh93
 3397 pts/8    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 3395

no problem, I had already done it, I only had to copy and paste

Wait. Is ksh93 doing the same thing?

ek@Io:~/source$ ksh93
$ (perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$"; :)
24918 *24918 24920

don't you think so?

ek@Io:~/source$ ps 24918 24920 | cat
  PID TTY      STAT   TIME COMMAND
24918 pts/4    S      0:00 ksh93
24920 pts/4    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 24918

oh gosh it optimised even more?

I think it's a different optimization. I think it doesn't spawn a subshell process at all.

I've heard of this. ksh93 simulates subshells for performance.

so it figures out it doesn't really need to create a subshell for this task, and just pretends to make one by grouping commands some other way?

It keeps track of changes to the shell environment and reverts them afterwards, yeah.

I have heard that happens. I think that's what's happening here. Let's test.

$ (for _ in {1..10}; do perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"' "$$"; done)
24960 *24960 25055
24960 *24960 25056
24960 *24960 25057
24960 *24960 25058
24960 *24960 25059
24960 *24960 25060
24960 *24960 25061
24960 *24960 25062
24960 *24960 25063
24960 *24960 25064

That was in ksh93. Now, in zsh:

Io% (for _ in {1..10}; do perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"' "$$"; done)
25078 *25084 25085
25078 *25084 25086
25078 *25084 25087
25078 *25084 25088
25078 *25084 25089
25078 *25084 25090
25078 *25084 25091
25078 *25084 25092
25078 *25084 25093
25078 *25078 25084

And in bash:

ek@Io:~/source$ (for _ in {1..10}; do perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"' "$$"; done)
332 *25121 25122
332 *25121 25123
332 *25121 25124
332 *25121 25125
332 *25121 25126
332 *25121 25127
332 *25121 25128
332 *25121 25129
332 *25121 25130
332 *25121 25131

Remember, the * is to remind us of how the number that follows it is the parent process of perl, not necessarily the PID of the subshell that runs perl.

Zsh exec'd itself on the last run I guess

Yeah. ksh93 just doesn't spawn a subshell for ( ). zsh does spawn a subshell, but the subshell replaces itself with perlon the last run. bash spawns a subshell and doesn't replace itself.

As expected, dash behaves the same as bash here:

$ (for _ in 1 2 3 4 5 6 7 8 9 10; do perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"' "$$"; done)
25163 *25170 25171
25163 *25170 25172
25163 *25170 25173
25163 *25170 25174
25163 *25170 25175
25163 *25170 25176
25163 *25170 25177
25163 *25170 25178
25163 *25170 25179
25163 *25170 25180

(dash doesn't support brace expansion.)

It turns out that dash does exec the last command in a subshell without forking at least when bash does, i.e., at least when it's the only command:

$ (perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
25198 *25198 25201

ek@Io:~/source$ ps 25198 25201 | cat
  PID TTY      STAT   TIME COMMAND
25198 pts/3    S      0:00 dash
25201 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 25198

Oh. Why did we think that it didn't?

Did we think it didn't?

haha well I did

Remember, this is not the same situation as starting a shell subprocess that isn't a subshell and running commands by passing them as the operand to -c.

I remember thinking that dash doesn't perform the optimization then.

We should probably test that. But first...

$ (:; perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$")
25198 *25198 25273

ek@Io:~/source$ ps 25198 25273 | cat
  PID TTY      STAT   TIME COMMAND
25198 pts/3    S      0:00 dash
25273 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 25198

$ (perl -we 'use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100' "$$"; :)
25198 *25614 25615

@EliahKagan so when I run those commands in ksh93, I get the Memory fault message in the pipe

ek@Io:~/source$ ps 25198 25614 25615 | cat
  PID TTY      STAT   TIME COMMAND
25198 pts/3    S      0:00 dash
25614 pts/3    S+     0:00 dash
25615 pts/3    S+     0:00 perl -we use English; my $ppid = getppid; print "$ARGV[0] *$ppid $PID\n"; sleep 100 25198

So dash actually behaves the same as zsh in terms of this optimization in a subshell!

o.O very interesting

@Zanna I'm not surprised -- or, I should say, I'm surprised, but not quite at that.

ek@Io:~/source$ ksh93
$ ./crash2 2>pipe
About to crash...
$

And on the other side of the named pipe:

Memory fault(coredump)

So in ksh93 it actually redirects the segfault message even when no grouping is used, as though it were written to standard output by the command itself, even though it isn't!

Um. The thing that is really weird is that, I typed exit in ksh93, then I typed enter a few more times just to separate it, with the intention of testing another shell, but I got:

$ exit



Segmentation fault (core dumped)

@Zanna (but not the Segmentation fault message, which I only get after typing exit, and only if I type exit as the next command after running ./crash)

Yeah. Same.

Ubuntu just told me that ksh93 crashed

What does ./crash 2>pipe give you when issued in an interactive bash shell?

zanna@toaster:~/playground$ ./crash 2>pipe
Segmentation fault (core dumped)

Yeah, so we get the same for that.

@Zanna Apport said that?

as expected. Nothing in the pipe, because the program didn't say anything

Right.

@EliahKagan yes, sorry I should be more accurate!

Do you still have the Apport window open?

no >_<

I'll try doing what I did again

Well you can just open the .crash file.

What's the output of:

ls /var/crash

Oh, hey. The reason I didn't get that was that I got it yesterday then forgot about it until now.

ek@Io:~/source$ ls -l /var/crash
total 11840
-rw-r----- 1 ek       whoopsie    75534 Nov 14 10:52 _bin_ksh93.1000.crash
-rw-r----- 1 ek       whoopsie 12043829 Nov 11 17:48 _usr_share_gns3_gns3-server_bin_gns3server.1000.crash
-rw-rw-r-- 1 ek       whoopsie        0 Nov 11 17:48 _usr_share_gns3_gns3-server_bin_gns3server.1000.upload
-rw------- 1 whoopsie whoopsie        0 Nov 11 17:48 _usr_share_gns3_gns3-server_bin_gns3server.1000.uploaded

I don't remember quite what I did that produced that crash report, though.

So it can be reproduced more simply:

ek@Io:~/source$ ksh93
$ ./crash
Memory fault(coredump)
$ exit
Segmentation fault (core dumped)
ek@Io:~/source$

$ ls -lrt /var/crash
total 164
-rw-r----- 1 zanna    whoopsie 67352 Nov 13 21:50 _usr_bin_marco.1000.crash
-rw-r----- 1 zanna    whoopsie 96053 Nov 15 12:42 _bin_ksh93.1000.crash
-rw-rw-r-- 1 zanna    whoopsie     0 Nov 15 12:42 _bin_ksh93.1000.upload
-rw------- 1 whoopsie whoopsie     0 Nov 15 12:42 _bin_ksh93.1000.uploaded

It looks like you submitted the report. If so, can you look up what you submitted?

(irrelevantly, marco keeps crashing lately)

I have no idea why it's as though ksh93 crashes when you quit it after a program crashed in it.

@EliahKagan how do I do that?

Do you have Apport set up to let you fill out a bug report on Launchpad?

hmm... the last couple of times Apport wanted me to submit a report, it took me to Launchpad, but this may have been before I installed 17.10. I haven't done anything to configure it

I don't see it here, but also I couldn't view it if I did, and I don't think it would let you either:

errors.ubuntu.com/?package=ksh&period=day

I don't see it

That's okay. We can debug it ourselves.

ek@Io:~/source$ gdb ksh93
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:

You can attempt to reproduce that symbolic stack trace on your system if you install the ksh-dbgsym package. Do you have the -dbgsym repos enabled?

apparently not

wiki.ubuntu.com/Debug%20Symbol%20Packages

The sh_done is on line 603:

anonscm.debian.org/cgit/collab-maint/ksh.git/tree/src/cmd/ksh93/…

thanks!

ok, I got the same stuff as you, only the memory addresses are a little different

So it seems to deliberately crash itself if the last command crashed:

	if(sig)
	{
		/* generate fault termination code */
		if(RLIMIT_CORE!=RLIMIT_UNKNOWN)
		{
#ifdef _lib_getrlimit
			struct rlimit rlp;
			getrlimit(RLIMIT_CORE,&rlp);
			rlp.rlim_cur = 0;
			setrlimit(RLIMIT_CORE,&rlp);
#else
			vlimit(RLIMIT_CORE,0);
#endif
		}
		signal(sig,SIG_DFL);
		sigrelease(sig);
		kill(getpid(),sig);
		pause();
	}

why?

I have no idea. I should say, it sends itself whatever signal terminated the last command, which will sometimes result in termination and sometimes not. So when that signal is SIGSEGV, it sends itself SIGSEGV. Also, I am not sure this is exactly what's happening. I should study the code further (code above that point is relevant because it's above there that sig gets set). However, it does't seem to crash when I run another command after ./crash:

ek@Io:~/source$ ksh93
$ ./crash
Memory fault(coredump)
$ :
$ exit
ek@Io:~/source$

yeah, I noticed that

I didn't realise that the Segmentation fault message was the shell segfaulting and not the program, but I guess that should be clear

that doesn't seem to be a very good idea

ek@Io:~/source$ ksh93
$ ./crash; :
Memory fault(coredump)
$ exit
ek@Io:~/source$ ksh93
$ :; ./crash
Memory fault(coredump)
$ exit
Segmentation fault (core dumped)
ek@Io:~/source$

@Zanna Neither had I! After all, all the previous times it looked like a shell was segfaulting, it had actually been replaced with a different process which was what segfaulted. In this case, though ksh93 is actually crashing. Artificially. But it is actually crashing.

I also noticed that the segfault message doesn't appear if the memory fault message is suppressed by piping

zanna@toaster:~/playground$ ksh93
$ ./crash | cat
$ exit
zanna@toaster:~/playground$

so... the shell didn't crash? let's try that in gdb

Well I assume it considers cat to be the last command run.

oh yes

After all, the exit status of the rightmost command in a pipeline is the exit status of the pipe, unless a shell option changes this behavior.

ek@Io:~/source$ ksh93
$ ./crash
Memory fault(coredump)
$ echo $?
267
$ ./crash | cat
$ echo $?
0
$ exit
ek@Io:~/source$

This, I don't fully understand:

ek@Io:~/source$ ksh93
$ set -o pipefail
$ ./crash | cat
$ echo $?
11
$ exit
ek@Io:~/source$

267... that's a lot of exit codes

what does pipefail do?

@Zanna A lot of exit codes? I don't understand.

@Zanna It makes the whole pipe return a failure status if any of the commands failed.

I mean, assuming there was a different reason for every exit status from 0-267

@EliahKagan so why are you surprised? :)

From the ksh93 manpage: manpages.debian.org/stretch/ksh/ksh93.1.en.html

But the exit status wasn't the same as the one from just ./crash. The exit status of ./crash was 267, the exit status of ./crash | cat with pipefail off was 0 which makes sense, but I would have expected the exit status of ./crash | cat with pipefail on to be 267, not 11. That's why I'm surprised.

@Zanna The program is not actually returning 267. It's not return at all--it terminates abnormally (i.e., crashes) instead. In this situation, the exit status the shell considers it to have had is constructed based on the information the shell receives about how it was terminated.

@EliahKagan oh I see...

@EliahKagan so the shell apparently has a different idea about what happened to the program in the second case

Actually maybe this makes sense.

Not the part where the shell deliberately picks a signal up off the street and eats it.

But the part where $? differs depending on whether or not the command ran in a pipeline.

lol

Let's see what bash does.

No, they're the same. Also they're different from either of the values of $? in ksh93. This is bash:

ek@Io:~/source$ ./crash
Segmentation fault (core dumped)
ek@Io:~/source$ echo $?
139
ek@Io:~/source$ set -o pipefail
ek@Io:~/source$ ./crash | cat
Segmentation fault (core dumped)
ek@Io:~/source$ echo $?
139
ek@Io:~/source$

I got the same result

All three of the same numbers?

zanna@toaster:~/playground$ ksh93
$ ./crash
Memory fault(coredump)
$ echo $?
267
$ exit
zanna@toaster:~/playground$ ./crash
Segmentation fault (core dumped)
zanna@toaster:~/playground$ echo $?
139
zanna@toaster:~/playground$ set -o pipefail
zanna@toaster:~/playground$ ./crash | cat
Segmentation fault (core dumped)
zanna@toaster:~/playground$ echo $?
139

oh oops, where did I run the other part in ksh... too many terminals

zanna@toaster:~/playground$ ksh93
$ set -o pipefail
$ ./crash | cat
$ echo $?
11

dash doesn't have pipefail but:

ek@Io:~/source$ dash
$ ./crash
Segmentation fault (core dumped)
$ echo $?
139
$

So where is that 267 coming from in ksh93?!

maybe it means "the writer of this program crashed it on purpose, that scoundrel" but only ksh93 is smart enough to realise

Makes sense. ksh93 crashes itself on purpose, after all. It could be a takes-one-to-know-one situation.

hahaha

So, per signal(7), SIGSEGV is 11. That explains the 11.

why didn't we get that in the other cases though?

Need to go afk. Back later.

k ttyl. I might type a few things so I don't forget and so you see them when you return. (And Videonauth might be interested.)

In ksh93, I don't know why it only gives the bare signal number, assuming that is what it's doing and this is not just a coincidence, and I don't know why it only does it for a command in a pipe other than the last command.

Hi @RobotHumans! How's it going?

Well enough. Just popping through. Lots of work to do today, we have a migration tomorrow. Since I'm in testing they write and hop new features through dev to test in a week. Can't write tests against incomplete features. So, I can only sort of start until it's on test. Then I write tests before we push to prod. On a monthly release cycle it means I have to double time it so we can push half way through the month.

Understood -- ttyl. (Sorry I didn't reply while you were in here. I don't want to take you away from your work by pinging you back in.)

@EliahKagan The pattern -- though not the explanation, not fully -- is apparent. I ran these commands in an interactive ksh93 shell:

dosig() { perl -we 'use POSIX; raise $ARGV[0]' "$1"; }
trysig() { printf 'Trying signal %d:\n' "$1"; dosig "$1"; echo "$?"; }
trypipedsig() { printf 'Trying signal %d in a pipe:\n' "$1"; dosig "$1" | cat; echo "$?"; }
set -o pipefail
for i in {1..15}; do trysig "$i"; trypipedsig "$i"; echo; done

I got:

Trying signal 1:
Hangup
257
Trying signal 1 in a pipe:
Hangup
1

Trying signal 2:
258
Trying signal 2 in a pipe:
2

Trying signal 3:
Quit(coredump)
259
Trying signal 3 in a pipe:
Quit(coredump)
3

Trying signal 4:
Illegal instruction(coredump)
260
Trying signal 4 in a pipe:
Illegal instruction(coredump)
4

Trying signal 5:
Trace/BPT trap(coredump)
261
Trying signal 5 in a pipe:
Trace/BPT trap(coredump)
5

Trying signal 6:
Abort(coredump)
262
Trying signal 6 in a pipe:
Abort(coredump)
6

Trying signal 7:

So normally ksh adds 256 to the signal number and considers that to be the exit status, but it uses the signal number itself as the exit status of a pipeline under set -o pipefail.

@EliahKagan Oh, KVM/Qemu cant create snapshots of EFI bios VM's

Why not?

just says it is not possible

Error creating snapshot: Operation not supported: internal snapshots of a VM with pflash based firmware are not supported

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/snapshots.py", line 503, in _do_create_snapshot
    self.vm.create_snapshot(xml)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1146, in create_snapshot
    self._backend.snapshotCreateXML(xml, flags)

from the details section

^cc @EliahKagan

i write here so i don't interrupt the talk in general chat, which could lead to confusion

Oh I'm definitely fine having two conversations at once in general chat. :)

But here is fine too.

yes me too, but the beginner youre talking with could get confused

This does relate to a topic that originated in AUGR though. So if you want, I can move these messages over. It's up to you.

if you think it is relevant do it

Yeah, that could happen. Though I can use reply pings to make the flow clear. Anyway, either place is definitely fine.

Either way is fine with me.

i have actually two problems on my machine, one is this, and the other is wine/playonlinux

What's the wine/playonlinux problem?

when i try to create a partition it hangs up and when i enter wine settings i see only blank windows or windows which are one pixel size

tried purging, reinstalling etc

so i guess it is a general problem with playonlinux/wine on 17.10

tho not being able to produce a VM snapshot is not much of a problem, the other VMs do this fine, just the one using omvf doesnt

anf this i only installed to get knowledge about efi myself, (having only legacy machines here myself)

I don't know much about playonlinux. Do you have problems with wine without playonlinux? Like if you install the wine package?

playonlinux bothers me the most, because i wanted to write a qa about how to install witcher III in wine and get it running

the packages install fine, im still in the process of googling around about it

@EliahKagan nice work