Csh Programming Considered Harmful

written by

:set revins

Makes inserting characters work backwards ... This would make a great prank to do with an open Vim session of a co-worker

@Carpetsmoker It's a great feature, it lets people who prefer top-down design get along with folks who like bottom-up design.

@Carpetsmoker Sounds like a question for the site, if you haven't already asked it.

... which I guess you did.

@derobert SIGSTOP "detaches" it from Vim

And doesn't seem to get re-attached on SIGCONT

I actually get the same if I just do it in my shell

@Carpetsmoker It shouldn't. It should just stop scheduling it. Not change its parent.

It doesn't change its parent

I tried it with sleep (not gitk), but it didn't work with sleep here.

jobs still lists it

Sorry, that wasn't clear—shouldn't change its parent's behavior

When I send SIGSTOP I get:

And mupdf doesn't do anything anymore (as expected)

When I send CONT, mupdf responds again, and my shell is also usable

Don't know why it doesn't work for you ... I tried this in tcsh, bash (shown), and zsh

I tried it in vim—I thought that was a question about running it on the vim prompt

Yes, it behaves the same in Vim

Odd. It doesn't here in vim. Though my bash behaves the same as yours.

:! is really just running the shell

32745 pts/61   Ss     0:00  |   \_ bash
  712 pts/61   Sl+    0:00  |       \_ vim
  722 pts/61   S+     0:00  |           \_ sleep 60

... so there isn't a shell in there.

hmm

Wait, if I use: set shell=/bin/sh before I do this, it doesn't work .... But it does work in my (default) tcsh

Interesting. I wonder if my vim is actually executing the shell, strace will find out!

I'm pretty sure :! runs a shell, at least on my system, as I often use shell aliases ...

anthony@Zia:~$ strace -e 'execve' -f -p 974
Process 974 attached with 2 threads
Process 1100 attached
Process 1101 attached
[pid  1100] execve("/bin/bash", ["/bin/bash", "-c", "sleep 2"], [/* 55 vars */] <unfinished ...>
[pid  1101] +++ exited with 0 +++
[pid  1100] <... execve resumed> )      = 0
[pid  1100] execve("/bin/sleep", ["sleep", "2"], [/* 55 vars */]) = 0
[pid  1100] +++ exited with 0 +++
[pid   974] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=1100, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---

OK, so yeah, it's going through the shell. And apparently bash just realized that it could optimize by using exec instead of fork/exec

... and I bet that's why I get different behavior. Bash wasn't around anymore to notice that its child had been stopped.

So it seems to work for tcsh and fish ... But not for bash, zsh, mksh, and dash ...

Ah, well, now we have an explanation.

I'm also getting rather annoyed by a certain user who keeps adding a boatload of noise to the site ...

Because it's noise?

I tried

It gets "fixed" back ... So well ...

Things like that ...

(comments on question, as well as the "answer" provided by said user)

Maybe my standards are just too high ... I don't know ... But I would really like to prevent this site becoming the mess of silly answers that SO sometimes is...

Well, it's a useless comment ... normally I would have let it go, but this is the nth useless comment/answer which just repeats what has already been said by said person, so I perhaps got slightly carried away ...

It does function as a quick way to point the asker to somewhere else on the network where the answer can be found—though really the person leaving the comment should be clear that the question is still welcome here (and since we're the vi site, should get a better/more detailed answer). But a quick comment answer is nice too, because sometimes you just need to get the #@(# task done.

I engaged him once :-) (well, twice, once also on Area51, just as it happens), and will avoid engaging unless absolutely required in the future.

(it wasn't my intention to start a discussion about this, btw, I was just annoyed that he seems somewhat impervious about even the most obviously wrong things, and added a bunch of answers days or even weeks later which just restate other answers ... :-/

That's a tl;dr right now, sorry :-( But yes, I know ... And I'm not suggesting obliterating anyone

:-)

@Carpetsmoker BTW, ^Z sends SIGTSTP not SIGSTOP. Though that doesn't work with bash either, at least here.

Yeah, I tried SIGTSTP too, that only works in tcsh and fish as well

Your new answer says ^Z sends SIGSTOP. By default both stop a process. The main difference is that a process can change the behavior of SIGTSTP, but it can't change SIGSTOP.

Perhaps it's a bourne-shell specific semantic, as the only 2 shells that don't do this, are not bourne shells

Ah

Thanks :-)

(SIGSTOP is handled entirely in the kernel, like SIGKILL)

So if SIGSTOP can't be caught by the application, how is it that different applications behave different then, hmm ...

@Carpetsmoker You're sending it to the sleep, which can't catch it. But the bash or tcsh which is its parent can behave differently (and apparently do).

SIGTSTP can be caught, that's how some programs do various things (up to completely ignoring it) when you press ^Z

Yeah, but SIGSTOP also doesn't work :-)

I suspect it's due to your earlier comment:

When starting from tcsh, I do get:

     `- vim
       `- tcsh
         `- mupdf

ack, how does one do code blocks?

@Carpetsmoker Four spaces, like normal. Though on chat, it's either then entire message or none at all

Ah

@Carpetsmoker Turns out that isn't it—do :!sleep 60 | cat and the bash sticks around, but still doesn't work.

oh

21087 ?        S      0:00  \_ /usr/bin/xterm
21089 pts/38   Ss     0:00  |   \_ bash
21099 pts/38   Sl+    0:00  |       \_ vim
21108 pts/38   S+     0:00  |           \_ /bin/bash -c sleep 60 | cat
21110 pts/38   S+     0:00  |               \_ sleep 60
21111 pts/38   S+     0:00  |               \_ cat

Correct. But they're not receiving the signal, their children are.

kill -STOP 21110 sends it to the sleep, not to the bash that's running it.

Right, yes, you said that

There should be a wait-variant handling it.

Possibly via WUNTRACED

Or WSTOPPED, etc. Depends on the wait variant.

man 2 wait will probably give details for your system...

Public service announcement: remember to activate keyboard shortcuts for the site in your user preferences.