3 ms·

I'm somewhere around 20 years in. I'm going to share my point of view with you, then let you make up your mind about what to do. :-) The command line by itself

by jt2190 10y ago

I'm somewhere around 20 years in. I'm going to share my point of view with you, then let you make up your mind about what to do. :-) The command line by itself is an old-school text editor, where the default behavior is to write programs that are executed then immediately thrown away [1]. We develop a habit of using the command line in a casual way, without realizing that it's a powerful programming environment. Once we realize that we're _programming_ with the command line, we can take deliberate steps to write better command line programs. We can: * learn how to capture our programs and execute them again later. * learn how to improve our programs using the edit -> execute workflow. * learn more about the commands and their options so that we can write more powerful programs * learn how to make our programs play well with other commands Note that I'm deliberately avoiding recommending a specific editor or programming language for your workflow. You can choose whatever works best for you. Instead I'd like to leave you with this thought: A - Always B - Be P - Programming Always. Be. Programing. Always be programming! [2] Treat every command like a program you intend to keep, and you'll start writing better and better commands; commands that you'll reuse, that will automate your workflow, that will help you spend your precious mental energy on thinking about how to solve important problems because you've delegated as much of the tedious grunt work to the computer as you possibly can. Best of luck, and enjoy the journey! [1] This is not strictly true but is useful as a starting point for this thought exercise. See the history command, for example. [2] (Since it's Christmas) https://www.youtube.com/watch?v=J_vSirIJEsY https://www.youtube.com/watch?v=J_vSirIJEsY

vram22 10y ago
Good advice. I used to be really into automating as much as possible of my work on the command line - even to the extent of writing one-line shell scripts or aliases (Unix) or batch files (Windows) to reduce the amount of typing of a command name [1] (e.g. one or two letters instead of five or more). Recently been doing it less. Need to increase it again. Helps a lot. [1] I know you probably don't mean only that sort of thing, there are bigger automations that can be done too, and have done those a lot too. Edit: a useful thumb rule - picked up years ago, IIRC, from the book The Unix Programming Environment by Kernighan and Pike, is to observe your own use of a command a few times, and then if you find yourself using it enough in a certain pattern, automate that via a script, with suitable parameters, etc. Could be something as simple as 'ltr' for 'ls -ltr' (with suitable changes to make it a script or a shell alias). In fact, many Unixes come with such an alias - 'll' for 'ls -l', because that command - 'ls -l' is typed so often in Unix.
skdotdan 10y ago
I appreciate your advice. I will try to apply it! I've already automated some tasks. However, I find it difficult to write useful bash commands that I will reuse later. Maybe I should learn a scripting programming language.
- macavity23 10y ago
  Learning Bash is both incredibly useful and will also make you richly appreciate more modern languages :)
  - skdotdan 10y ago
    Okay :)
- jt2190 10y ago
  > I find it difficult to write useful bash commands that I will reuse later. Try to avoid "pre-judging" the usefulness of scripts. As another commented mentioned, something as simple as: ls -l may be useful to you. It also helps establish the habit of editing (saving) the script before you execute it. So just write some scripts and see if you use them again. You will probably end up with too many, but that's ok, because you can remove the unnecessary ones later, and you'll have gotten extra practice creating the scripts in the first place. > Maybe I should learn a scripting programming language. That's really your preference based on your need for portability (i.e. minimizing the dependencies required to run the script.) Using Python or Perl is perfectly fine for these scripts, but they do require that the system has one of those languages installed. If you're doing a lot of work on machines that you do not administer, it's more likely that Bash is already there.

by jt2190 10y ago

vram22 10y ago

Good advice. I used to be really into automating as much as possible of my work on the command line - even to the extent of writing one-line shell scripts or aliases (Unix) or batch files (Windows) to reduce the amount of typing of a command name [1] (e.g. one or two letters instead of five or more). Recently been doing it less. Need to increase it again. Helps a lot. [1] I know you probably don't mean only that sort of thing, there are bigger automations that can be done too, and have done those a lot too. Edit: a useful thumb rule - picked up years ago, IIRC, from the book The Unix Programming Environment by Kernighan and Pike, is to observe your own use of a command a few times, and then if you find yourself using it enough in a certain pattern, automate that via a script, with suitable parameters, etc. Could be something as simple as 'ltr' for 'ls -ltr' (with suitable changes to make it a script or a shell alias). In fact, many Unixes come with such an alias - 'll' for 'ls -l', because that command - 'ls -l' is typed so often in Unix.

skdotdan 10y ago

I appreciate your advice. I will try to apply it! I've already automated some tasks. However, I find it difficult to write useful bash commands that I will reuse later. Maybe I should learn a scripting programming language.

macavity23 10y ago
Learning Bash is both incredibly useful and will also make you richly appreciate more modern languages :)
- skdotdan 10y ago
  Okay :)
jt2190 10y ago
> I find it difficult to write useful bash commands that I will reuse later. Try to avoid "pre-judging" the usefulness of scripts. As another commented mentioned, something as simple as: ls -l may be useful to you. It also helps establish the habit of editing (saving) the script before you execute it. So just write some scripts and see if you use them again. You will probably end up with too many, but that's ok, because you can remove the unnecessary ones later, and you'll have gotten extra practice creating the scripts in the first place. > Maybe I should learn a scripting programming language. That's really your preference based on your need for portability (i.e. minimizing the dependencies required to run the script.) Using Python or Perl is perfectly fine for these scripts, but they do require that the system has one of those languages installed. If you're doing a lot of work on machines that you do not administer, it's more likely that Bash is already there.