251–260 of 341 posts
Learning to use the shell and learning SQL are the two skills that have stayed relevant throughout my entire 20 year career. Other tools and languages come and go, but the shell and SQL just keep on providing value.
Earlier quoted context omitted.
Yup, it seems that shell embedded in YAML is pretty much a pattern now (Github Actions, Gitlab, Kubenetes, Travis CI, sourcehut, etc.) And I think it's growing beyond CI/CD -- that is, Github actions is a more general platform than Travis CI, etc. Good example: https://lobste.rs/s/oeelem/using_github_issues_as_hugo_front... My pet peeve is that YAML is a terrible syntax for a shell script, i.e. there are if statement…
It is not a very pretty pattern but the value on GA is so high for me these days, I just fight it until I get what I need. I think there are probably very elegant ways to combine yaml and shell scripting, maybe by careful factoring of things into their own actions. I hope so. I will check out oil.
Since JSON is valid YAML, it's possible to generate JSON from an Oil configuration with embedded and parsed shell, rather than using YAML. (Actually there's no problem generating YAML either, but I suppose it's easier to think about.)
Example: I changed my own configs to use .yml.in and .yml and it worked on both Travis CI and sourcehut.
https://github.com/oilshell/oil/tree/master/.builds
Some brainstorming here on this feature:
https://github.com/oilshell/oil/wiki/Config-Dialect
The benefit would be that it would validate your syntax and possibly your schema locally, not remotely. Some services have command line tools, but I'm sure they don't validate your shell, only the configuration.
Another benefit is the ability to reuse code and configuration. For example, my .builds/ dir has a fair bit of redundancy in its configuration, and that could be "factored" with a real language. YAML has a limited I'm looking for feedback on Oil, as well as the YAML + shell replacement idea. I hope that Oil can be a flexible language that will let people write these sorts of front ends for many cloud services, i.e. "distributed shell scripts". And eventually enable portability across clouds too.
I used to think this way as well, but out of necessity, had to work specifically with a commercial IDE for some time. Turns out, if you are confident learning the keybindings of a robust IDE is worthwhile (e.g. you know that you must use it for some particular project for a decent amount of time) the investment pays off just as well as learning shell commands. A good IDE can do everything a cobbled together shell pip…
> People like to pretend that learning shell commands is somehow better because it's more portable, No, it's better because if you aren't doing exactly the workflow an IDE or GUI tool designer has envisioned, it is almost invariably much easier to do it in shell (and then make it a script and then bind it to a command in your IDE or GUI tool, if they support that) than to beat the non-shell tool into, first, doing wh…
Modern IDEs have shell built-in so when I finish coding, I can just open up a terminal inside IDE to run shell scripts. Effectively I'm getting the best of both worlds.
I never knew that I have to follow some sort of rails laid by IDE designers, which I think it's a very common misconception by people who dislike IDEs.
Earlier quoted context omitted.
>The Linux man pages are upside down. Examples don't come till the very end, if at all. You only learn the tool once. Every subsequent time you visit the man page, the information you're probably looking for is frontloaded. Just scroll to the bottom if you want examples?
I always thought someday I would become a hardcore Linux hacker and know all the commands and flags but the reality is I have to relearn every time. Who spends that much time just in the command line these days? I’m sure some people do but I don’t know what they do unless its CTFs or security related.
I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
At least when you go to Stack Overflow or read the man page, if you find an answer, then it is likely to work. In contrast, if you go to Stack Overflow to find out how to do something with a GUI program, there's a good chance that the answer you find is for a different version than you are working with, and does not help at all.
The following sets up a key binding to grab interesting lines from the history, throw them into a file, and pop it up in an editor: # put interesting lines from history into a file, open an editor function h2e() { echo "#! /bin/bash" > "$3" history | tail -n"$1" | egrep "$2" | sed -re 's/\s*[0-9]+\s+//' >> "$3" "${EDITOR:-emacs}" "$3" } # prompt for h2e's arguments function h2ei() { read -p 'num. lines [1]: ' lines r…
So you would run "h2ei 10 somepattern out.txt"? Which would put the last 10 lines matching some pattern to the txt file?
In practice, I will do something, realize that the thing I just did over the last several minutes could be useful--or the core of something more general--and then strike F12 to start h2ei. At the prompts, I'll generally give it a nice round number like 10 or 20 or 50 lines, leave the default pattern, and set the filename to be something evocative in ~/bin. An editor will immediately open on my new shell script, and I can trim it down and continue hacking on it from there.
The key idea is that I get an easier path from doing something ad hoc to creating something more useful in the long run.
I used to think this way as well, but out of necessity, had to work specifically with a commercial IDE for some time. Turns out, if you are confident learning the keybindings of a robust IDE is worthwhile (e.g. you know that you must use it for some particular project for a decent amount of time) the investment pays off just as well as learning shell commands. A good IDE can do everything a cobbled together shell pip…
I can just never get past the arg/flag inconsistency/complexity across commands. Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. But as it is, I spend more time dealing with idiosyncracies of a command than I do expressively piping stuff. Perhaps if Rust had five mutually incompatible borrow-checkers which get…
> Perhaps if the docs started with a simple example of what has been seen over time to be the most common incantation for each command it might be tolerable. You might enjoy https://cheat.sh which is usable via curl: `curl cheat.sh/grep`
I used to think this way as well, but out of necessity, had to work specifically with a commercial IDE for some time. Turns out, if you are confident learning the keybindings of a robust IDE is worthwhile (e.g. you know that you must use it for some particular project for a decent amount of time) the investment pays off just as well as learning shell commands. A good IDE can do everything a cobbled together shell pip…
If you work with mechanical or electrical engineers, then you're going to run into Windows machines pretty quick, and then you need to convince them to install minGW to run your shell scripts. Sure, shell scripts are portable between Mac and *nix, but you're leaving out a large elephant.
But now you can use Linux subsystem for Windows. I don’t have much experience with this so I’m not sure how well it works in practice but most people seem to rave about it.