4 ms·

> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment whe

> I quite seriously believe that a 1000 line shell script only exists out of error. Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. > Unlearning bash-isms is not a liberty I can afford, as I need to be proficient when I SSH into a machine I do not own or control. This is a slippery slope. I have heard things like, "don't make your own custom aliases / shell functions, because they won't be available when you SSH to another machine." Forcing yourself to always use the lowest common denominator of software is not a fun path.

chubot 9y ago
Yes, absolutely. Oil has a principled representation of the interpreter state, so it should be easy to write a debugger. (Although note that bash actually has a debugger called bashdb, which I didn't know about until recently, and I've never heard of anyone using it.) One intermediate step I would like to take is to provide a hook to dump the interpreter state on an error (set -e). Sort of like a "stack trace on steroids". If anyone is running shell cron jobs in the cloud and would like this, please contact me at andy@oilshell.org. I want to give people a reason to use OSH -- right now there is really no reason to use it, since it is doing things bash already does. But I think a stack trace + interpreter dump in the cloud (like Sentry and all those services) would be a compelling feature. I'm looking for feedback on that. Shell scripts have a very small amount of in-process state, so it should be easy to dump every variable in the program. Also some kind of logging hook might be interesting for cloud use cases.
rollcat 9y ago
> Forcing yourself to always use the lowest common denominator of software is not a fun path. Second this. Been there, and back, and there again, and recently back again. Customize the hell out of your shell, make it your place, make it nice. You're spending your day there, every day. Treat it like you'd treat your work desk. If it's a stranger's machine, well, OK, suffer through the 10 minutes of troubleshooting, an occasional session with busybox also helps keep "pure POSIX" skillset fresh. If you're becoming a regular there, it's time to think how to make your dotfiles portable. google.com/search?q=dotfiles
- jsmthrowaway 9y ago
  While I appreciate your perspective, I think it’s more from the “occasional SSH to a foreign server” mindset. Scaling “the way I work in a shell” to huge fleets is a nonstarter, and as a working SRE, has been the biggest thing holding me back from zsh, fish, and other alternatives. OTOH, I’m also against, for example, installing zsh fleetwide in production fleets to accommodate choosy folks. So I’m on both ends of the problem, and know it.
  - racer-v 9y ago
    It's actually not that difficult to maintain context if you use completely different shells (with different-looking prompts) on your own machine vs the fleet. It's like code-switching when you talk to your friends at the bar vs co-workers.
  - rollcat 9y ago
    - As soon as you have more than 5 boxes, you need different tools for your everyday tasks, interactive SSH sessions just don't work. But you know that already. - So you've found yourself SSH'ing into a particular box, because that's just the best way to work on a problem. Either it's a pet box (in which case it makes total sense to drop your dotfiles there), or it's a cattle box and you don't care about the trash you left behind, because autoscaling will clean it up for you.
- arghwhat 9y ago
  My zsh/nvim/... dotfiles are portable and compatible with FreeBSD, macOS and a bunch of Linux distributions, but it's absolutely unacceptable to run those on a machine I don't control. You don't mess with configuration on another guy(ette)'s server. My setup is customized, but the core experience is kept relatively untouched. If someone experiences a problem, I need to be able to debug it in place efficiently. I write drivers for the company's hardware for a living—troubleshooting takes more than 10 minutes.
arghwhat 9y ago
> Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. My approach to that problem is to just instrument scripts to write out the command line every time a tool is called, and infer the logic behind it. When I started here, build/package/test on Windows were controlled by 6000 lines of Perl... A printing version of system() and a few days later, it's 40 lines of batch and 150 lines of Python. > Forcing yourself to always use the lowest common denominator of software is not a fun path. Never said it was fun. Also, I need to be able to use the lowest common denominator, I don't necessarily have to be the lowest common denominator. I use a configured zsh and nvim instance myself, but I take care to ensure that if I'm stuck with vi and (ba|da|k|c)sh, I'm still productive. The core behavior of my VIM instance stays close to stock, but it has a bunch of extras like fuzzy search, linting, a nice theme, etc. And, if I can make a choice without caring, my needs for a shell and a programming language are in direct opposition. I want my shell to put all of its energy into a useful interactive experience.
deadbunny 9y ago
> "don't make your own custom aliases / shell functions, because they won't be available when you SSH to another machine." If you're logging into a machine to the point you're editing files or require your customizations in this day and age you're doing it wrong IMHO.
- racer-v 9y ago
  Doing what wrong?
- arghwhat 9y ago
  And what would you recommend instead, then?

chubot 9y ago

Yes, absolutely. Oil has a principled representation of the interpreter state, so it should be easy to write a debugger. (Although note that bash actually has a debugger called bashdb, which I didn't know about until recently, and I've never heard of anyone using it.) One intermediate step I would like to take is to provide a hook to dump the interpreter state on an error (set -e). Sort of like a "stack trace on steroids". If anyone is running shell cron jobs in the cloud and would like this, please contact me at andy@oilshell.org. I want to give people a reason to use OSH -- right now there is really no reason to use it, since it is doing things bash already does. But I think a stack trace + interpreter dump in the cloud (like Sentry and all those services) would be a compelling feature. I'm looking for feedback on that. Shell scripts have a very small amount of in-process state, so it should be easy to dump every variable in the program. Also some kind of logging hook might be interesting for cloud use cases.

rollcat 9y ago

> Forcing yourself to always use the lowest common denominator of software is not a fun path. Second this. Been there, and back, and there again, and recently back again. Customize the hell out of your shell, make it your place, make it nice. You're spending your day there, every day. Treat it like you'd treat your work desk. If it's a stranger's machine, well, OK, suffer through the 10 minutes of troubleshooting, an occasional session with busybox also helps keep "pure POSIX" skillset fresh. If you're becoming a regular there, it's time to think how to make your dotfiles portable. google.com/search?q=dotfiles

jsmthrowaway 9y ago
While I appreciate your perspective, I think it’s more from the “occasional SSH to a foreign server” mindset. Scaling “the way I work in a shell” to huge fleets is a nonstarter, and as a working SRE, has been the biggest thing holding me back from zsh, fish, and other alternatives. OTOH, I’m also against, for example, installing zsh fleetwide in production fleets to accommodate choosy folks. So I’m on both ends of the problem, and know it.
- racer-v 9y ago
  It's actually not that difficult to maintain context if you use completely different shells (with different-looking prompts) on your own machine vs the fleet. It's like code-switching when you talk to your friends at the bar vs co-workers.
- rollcat 9y ago
  - As soon as you have more than 5 boxes, you need different tools for your everyday tasks, interactive SSH sessions just don't work. But you know that already. - So you've found yourself SSH'ing into a particular box, because that's just the best way to work on a problem. Either it's a pet box (in which case it makes total sense to drop your dotfiles there), or it's a cattle box and you don't care about the trash you left behind, because autoscaling will clean it up for you.
arghwhat 9y ago
My zsh/nvim/... dotfiles are portable and compatible with FreeBSD, macOS and a bunch of Linux distributions, but it's absolutely unacceptable to run those on a machine I don't control. You don't mess with configuration on another guy(ette)'s server. My setup is customized, but the core experience is kept relatively untouched. If someone experiences a problem, I need to be able to debug it in place efficiently. I write drivers for the company's hardware for a living—troubleshooting takes more than 10 minutes.

arghwhat 9y ago

> Perhaps the best use case for Oil is to provide a debugging environment where you can figure out what your legacy shell scripts are doing, and rewrite them in another language. My approach to that problem is to just instrument scripts to write out the command line every time a tool is called, and infer the logic behind it. When I started here, build/package/test on Windows were controlled by 6000 lines of Perl... A printing version of system() and a few days later, it's 40 lines of batch and 150 lines of Python. > Forcing yourself to always use the lowest common denominator of software is not a fun path. Never said it was fun. Also, I need to be able to use the lowest common denominator, I don't necessarily have to be the lowest common denominator. I use a configured zsh and nvim instance myself, but I take care to ensure that if I'm stuck with vi and (ba|da|k|c)sh, I'm still productive. The core behavior of my VIM instance stays close to stock, but it has a bunch of extras like fuzzy search, linting, a nice theme, etc. And, if I can make a choice without caring, my needs for a shell and a programming language are in direct opposition. I want my shell to put all of its energy into a useful interactive experience.

deadbunny 9y ago

> "don't make your own custom aliases / shell functions, because they won't be available when you SSH to another machine." If you're logging into a machine to the point you're editing files or require your customizations in this day and age you're doing it wrong IMHO.

racer-v 9y ago
Doing what wrong?
arghwhat 9y ago
And what would you recommend instead, then?