This is why whenever I’m writing anything complicated in bash, I open up my editor first. It saves me a lot of pain later. Sure you can recover from that pain, and the OPs solution was somewhat ingenious, but why not avoid that pain in the first place?
Work smarter not harder :D
Part of the problem with that is you’re not working on anything complicated in bash. At least it doesn’t start. So you just “hmm lets find all those files, right…soooo..no I don’t need this one, let’s pipe that out… Of wait what if I now extract the path I could directly…”
And your flow is just arrow-up, tweak, enter. I can totally see the scenario from the article as viable. So you got it running, but will it hold? “Let’s just keep it in screen for two days for the next drop to check if it worked. If it does well we’ll write a proper daemon with all…” Then life comes and six months later you’re learning gdb :)
My modus operandi is that but to stop it and copy it regardless before trying the long run.
Heck I’d even work directly on a sh file and run that instead. I’ve got burnt enough times that it’s just by default for me to make sh file first.
Yeah exactly… I cannot remember long commands so I just type them into a text editor by default. Pretty much anything more than “rm foo” goes in a script I save somewhere.
I gave some examples in this post: Shell Scripts Are Executable Documentation. Although I have to admit it seems to serve better as documentation for myself than others, since there are a lot of people who don’t like reading shell scripts!
This is awesome, it reminds me of a similar post I once made that also involved using a debugger and calling a c function from within the process. Except in my case I had to compile a function and dlopen it into the running binary.
Obviously hindsight it always 2020, but knowing some of these tricks can save hours of time, and it’s just so much fun!
Neat trick. I would be too scared of accidentally segfaulting it while attaching gdb to try this. I would consider scanning its memory (by reading files in /proc/pid) looking for ASCII strings instead.
That’s some serious king-fu. There are a lot of tips here I can use the next time I’m faced with a bash/OS mystery.
Thanks for the link!