The tip about getting the binary from /proc is also helpful if you upgrade screen/tmux and the newer version doesn't allow you to reattach to it. With that you can use the old one to reattach, work your magic, and restart the session.
Good question. Well, when you have forgotten everything about a 10 lines long command line you wrote 6 months ago, you don't know what side effects a signal may cause... You don't have the heart to signal anything, except surrender. Luckily, I found a workaround :-)
Since the shell where I wrote the command is still executing, the .bash_history has no mention of it (bash saves the commands in the history file when it exits). As for the up arrow, it would mean interrupting the commands - and I didn't want to :-)
I recently did exactly the same, it's those times when everything with similar functionality depending on what context you are in blurs together because you should probably be outside, taking a walk, or staring at a tree.
However, reaching for one way of doing things when the justification for the other way of doing things is because you've seen them done that way more, is not really good justification. So maybe that blurry brain is a good brain sometimes, in retrospect.
It's just that in some emergency situations, where for example someone deleted a lot of files on the disk, you might not have /bin/cat or /bin/cp anymore.
And cp would have also saved permissions (the executable bit). Not that GDB would have an issue without it, as the OP showed it can look for symbols inside an ELF regardless of the inode bits.
wouldn't a simple Perl script and cron do the job I recall back I 2000 doing 20 line script in an afternoon that tied together one of the major exhibits at the millennium dome that my employer was sponsoring - the 3d scanner booth thing from memory.
However, the post illustrates an important feature I often see overlooked: the systems we build on top of are not just black boxes. We should not be afraid to really understand how they work, opening up source code, asking questions like, "what the heck is this /proc/NUMBER section of the filesystem?" And I think this post illuminates that in a pretty fun way.
You're telling me that you've never - under tremendous pressure - hacked things that quickly "handle" something - and then forgotten about them till much later?
I didn't want to send any signal - because I could not remember what I had done, and was afraid for sideeffects (I did remember that the logic had to do with database actions).
I wanted to see the command without "messing" with the execution in any way - after all, it was running fine for 6 months, why interrupt it (and face potential effort in fixing messed up state) if I could see the command "from the outside"?
C-z is actually your friend here. I've never ever seen SIGSTOP affect anything negatively. I even SIGSTOP Mac OS X apps sometimes. They just beachball until you SIGCONT them, then they happily continue, oblivious.
If you're worried about timing out of the process being unresponsive, just C-z and then "bg" real quick. Then you can up arrow at your leisure and "fg" when you've copied the command away...
zsh does the right thing, when you bg it back it recovers the loop as it was.
Bash seems to forget about the loop and only recovers the "sleep 1", when it starts executing again it sleeps 1 and exits.
If you want to make sure it will work you should wrap it around another bash:
Other classics: dumping the memory of an active process (check my GitHub utils repo, I have it there) and redirecting the standard output AFTER you've started a process.
Ah, dumping memory. I once took the dump-and-restart code from GNU Emacs, and planted it into GNU Make. I was then able to read a large and complex Makefile (consisting of included sub-Makefiles throughout a large tree) which took 30 seconds to process, dump the image to disk (with make --dump), and then use the dump to run incremental builds which were able to kick off build recipes almost instantly!
My mom has Alzheimer's disease. I either sympathize with your situation, or if you were using it as an expression, I find the misuse a bit offensive. Particularly in this context for me, it brings up a painful memory of one of the first signs of Alzheimer's in my mom, when she called me because she had entirely forgotten her computer password.
As a sidenote to anyone reading this, I really appreciate that the Hacker News community occasionally posts and upvotes Alzheimer's articles. I read every one that I see.
Anyway, I beg that you might not use "Alzheimer's" as an expression for forgetfulness, just as you might avoid calling someone "ADD" when they multitask to a fault.
It's worth noting that the author appears to be in Greece. Assuming he's a non-native speaker, it doesn't really make sense to be "offended" by his misuse of the term.
Maybe a better way to put it would be "We don't typically use 'Alzheimer's' to refer to forgetfulness because it brings up negative emotions for some people."
It's considered 100% normal in everyday speech here in Greece, to use the name of the disease as an excuse when you forget something. I had absolutely no intent to offend anyone, and my heart goes out to the people fighting this disease - and the ones taking care of them.
I guess it's yet another cultural difference I was not aware of...
Greek language is more about emotion than content. Hyperbole is used to emphasize meaning. I cannot forget he first time I went to Greece and my aunt kissed me, bit me, and said she was going to eat me. I was 6. I was petrified. It is common in Greece to express disappointment affectionately by saying ' I am going to kill you'. It is our cultural ignorance in the US that makes Americans easy targets for ridicule. If we project ourselves as a superpower to the world, then where indeed are our superpowers of understanding?
On the other hand, the Internet is a multicultural and multinational community. It does make some sense to shed the typically American “right to not be offended” when you browse the Web.
Just as much as you ask for your culture to be respected, respect other cultures by acknowledging their more offensive and black humour and not taking everything personally.
You can configure it though, to be much larger than its default settings. Still, 6 months... he'd probably have to hack it as he did, no matter what :-)
Some people here are already rather mean in their comments - imagine what would happen if I revealed The Magic CmdLine (TM)...
No, that privilege is reserved for the Inner Circle :-)
But I'll give you a teaser... It involved a lot of ImageMagick and "pdfimages" and "zxing" and "tesseract" and "pdfjoin" invocations... and the uploaded files were PDFs with scanned barcoded pages.
(I can imagine the gory details tbh - it sounds like there is every chance I have had a very similar command for a pretty similar purpose running for a good long while now... except mine's in a VBScript..!)
Across the road (on Reddit/programming), a commenter already described me pretty well:
"Everything about your (rather interesting) story... reaffirms everything I know about Linux sysadmins - if you encounter a problem, your go-to solution is to write a script ... Honestly, you guys would script a sandwich if you could :P"
The only thing wrong in that sentence, is that I am not a sysadmin (hence the knowledge of the Dark Arts - of GDB :-)
I appreciate the spirit and the knowledge that you wrote this blog post with BUT -
The extra few seconds to put this in a .sh file in the first place ... priceless. Even for the basic case of debugging it and getting it working.
I don't think in the 20-25 years I've been "doing" unix that I've ever done this (I doubt anyone that has worked with me considers me ocd fwiw but this is beyond the pale).
Behaviors like this lead to "magic" work environments and are just pants on head places to work at/with.
I would be really mad the first time I found you doing this and I'd look for a different work situation for one of us the second time :)
When I read the problem description, I decided to try and solve it myself.
I used gcore to dump the running bash process, then ran strings on the core dump, then grepped for likely command line stuff. 'while' is reasonable choice for a loop. There aren't that many strings in the dump file in any case, most of the sizeable ones are function definitions and environment variables.
Relying on gdb makes getting to the right data much more precise, but my approach took about 20 seconds.
80 comments
[ 3.1 ms ] story [ 145 ms ] threadIt seems that the take-away lesson from the article is that you should save it in a bash script.
However, reaching for one way of doing things when the justification for the other way of doing things is because you've seen them done that way more, is not really good justification. So maybe that blurry brain is a good brain sometimes, in retrospect.
As to 'cp' vs 'cat': neither is a builtin, so they both are risky. What if you also accidentally did a rm -rf / on that system?
Mac OS X doesn't have a /proc filesystem, so I cannot test it, but from reading the man page
should read all of bash into $bash, if it isn't ridiculously large, and should then complete the copy.A Jedi? Maybe at getting himself out of the quicksand he lays himself into ...
However, the post illustrates an important feature I often see overlooked: the systems we build on top of are not just black boxes. We should not be afraid to really understand how they work, opening up source code, asking questions like, "what the heck is this /proc/NUMBER section of the filesystem?" And I think this post illuminates that in a pretty fun way.
You're telling me that you've never - under tremendous pressure - hacked things that quickly "handle" something - and then forgotten about them till much later?
Jeez, tough crowd :-)
I wanted to see the command without "messing" with the execution in any way - after all, it was running fine for 6 months, why interrupt it (and face potential effort in fixing messed up state) if I could see the command "from the outside"?
And that I did :-)
If you're worried about timing out of the process being unresponsive, just C-z and then "bg" real quick. Then you can up arrow at your leisure and "fg" when you've copied the command away...
Apparently C-z followed by fg is not bulletproof...
zsh does the right thing, when you bg it back it recovers the loop as it was. Bash seems to forget about the loop and only recovers the "sleep 1", when it starts executing again it sleeps 1 and exits.
If you want to make sure it will work you should wrap it around another bash:
should work fine.sleep(1) is the only process that can be suspended in this command. When you "fg", the suspended sleep(1) is signaled, and resumes. And then it exits.
When you do this in a subshell (in parens), you suspend/resume the subshell in its entirety, which capture the loop construct.
Why does it work in zsh?!
――――――
¹ — http://www.stclairsoft.com/AppTamer/index.html
Other classics: dumping the memory of an active process (check my GitHub utils repo, I have it there) and redirecting the standard output AFTER you've started a process.
I only wish that in a site called 'Hacker News', it would be technical comments like yours at the top of this discussion. Oh well...
commands ... call d(cons(form)) call symbol_name(t) cont end
It really is a marvelous tool - unfortunately, people don't know anything except the basics (if that)
How that one got by me is a mystery - let's chalk it up to stress and pretend it never happened :-)
Fantastic article though - I've learned a couple of things from it, thank you.
As a sidenote to anyone reading this, I really appreciate that the Hacker News community occasionally posts and upvotes Alzheimer's articles. I read every one that I see.
Anyway, I beg that you might not use "Alzheimer's" as an expression for forgetfulness, just as you might avoid calling someone "ADD" when they multitask to a fault.
Maybe a better way to put it would be "We don't typically use 'Alzheimer's' to refer to forgetfulness because it brings up negative emotions for some people."
I guess it's yet another cultural difference I was not aware of...
Just as much as you ask for your culture to be respected, respect other cultures by acknowledging their more offensive and black humour and not taking everything personally.
Some people here are already rather mean in their comments - imagine what would happen if I revealed The Magic CmdLine (TM)...
No, that privilege is reserved for the Inner Circle :-)
But I'll give you a teaser... It involved a lot of ImageMagick and "pdfimages" and "zxing" and "tesseract" and "pdfjoin" invocations... and the uploaded files were PDFs with scanned barcoded pages.
(I can imagine the gory details tbh - it sounds like there is every chance I have had a very similar command for a pretty similar purpose running for a good long while now... except mine's in a VBScript..!)
Across the road (on Reddit/programming), a commenter already described me pretty well:
"Everything about your (rather interesting) story... reaffirms everything I know about Linux sysadmins - if you encounter a problem, your go-to solution is to write a script ... Honestly, you guys would script a sandwich if you could :P"
The only thing wrong in that sentence, is that I am not a sysadmin (hence the knowledge of the Dark Arts - of GDB :-)
The extra few seconds to put this in a .sh file in the first place ... priceless. Even for the basic case of debugging it and getting it working.
I don't think in the 20-25 years I've been "doing" unix that I've ever done this (I doubt anyone that has worked with me considers me ocd fwiw but this is beyond the pale).
Behaviors like this lead to "magic" work environments and are just pants on head places to work at/with.
I would be really mad the first time I found you doing this and I'd look for a different work situation for one of us the second time :)
Thanks for the cool post.
I used gcore to dump the running bash process, then ran strings on the core dump, then grepped for likely command line stuff. 'while' is reasonable choice for a loop. There aren't that many strings in the dump file in any case, most of the sizeable ones are function definitions and environment variables.
Relying on gdb makes getting to the right data much more precise, but my approach took about 20 seconds.