1. 15
  1. 8

    I didn’t understand the problem. Could someone explain?

    1. 4

      The problem is that some command line tools, like RipGrep, can have you typing out a command that is over 200 characters long. Having a small wrapper script for that can enable a lot of small gains, both in documenting how to use the tool, and making it less painful access more involved command parameters, since you don’t have to type them out so many times.

      This is a small productivity tip, not an earthshattering one, though I do find it moves some tools from “I use this occasionally” to “I can use this a lot more often”

      1. 1

        I still don’t get it. Competent shells support completion and some, like zsh, do fuzzy completion. It would be silly to manually type out 200 characters for a single command. You seem to be using windows though, so maybe this post is better tagged ‘windows’?

        1. 12

          No, I don’t think it’s specific to Windows (other than the fact that they are using batch scripts as their medium). Or 1995, for that matter, as another commenter cheekily suggested. I do this kind of thing all the time despite the fact that I use a “competent” shell (zsh with auto completions enabled). For example, just recently, I was hunting around trying to figure out how to grab an mp3 off a video off of YouTube. I do this very occasionally, so the command isn’t something I keep in my memory. So I just wrote youtube-dl-mp3.

          exec youtube-dl --extract-audio --audio-format mp3 "$@"

          The name means I’m likely to discover it when tab completing youtube-.

          1. 5

            Same for me. Shells make it easy to write small scripts that you can keep around like bookmarks. There’s no shame in finding it easier to remember/type the name of a short script you wrote for your need rather than remembering how a program works, even if it’s a well designed one.

            1. 3

              Now that I’ve picked it up as a pattern, I’d be more than keen on doing something similar on Linux when it makes sense to do so.

              1. 2

                I tend to do the same, except I keep these short scripts/commands in my notes rather than as standalone executable files (unless I need it often).

                1. 1

                  Speaking of “competent” shells, fish has abbreviations, so (e.g. in its example) gco can expand to git checkout. And functions and aliases (which also understand completion for the aliased command!) can be saved on-disk automatically. Fuzzy search also gives you the ability to just type mp3 and hit the up arrow until you get to this command in history.

                  Not to say “my favorite shell is better” - presumably zsh and other friends can do all of this too - just wanted to add other ways of doing this, for interested comment-readers.

                  1. 1

                    Nice yeah. If I’m understanding correctly, I believe my shell (zsh) has all of that too. Although it had to be configured. But it wasn’t too hard. Took about a day to set everything up.

                2. 3

                  This isn’t a Windows problem as much as a problem with people using cmd. It’s an antiquated shell that was never good to begin with. Now they refuse to use a modern shell like PowerShell. A more fitting tag would be “historical” and to reframe the article as “how we would do this we were in 1995”.

                  1. 4

                    It may sound funny to you, but I’ve actually started to warm up to using CMD a lot more. I’ve more or less had to use it, and batch scripts, at my current job, since we inherited a lot of code that uses batch scripts. One thing I like about CMD is is that it manages to be very low latency on Windows, where both PowerShell and mingw have a lot more latency around starting processes.

                    I realize this is a very different story on Linux and co, and there I usually end up using an alias or the like. But between this and and a jumplist, it makes working with CMD a whole lot less painful.

                    1. 1

                      Inheriting a lot of code is a valid reason to use the language, but I would still attempt to migrate to PowerShell if possible in that case as CMD is notorious for arcane incantations to accomplish things. It’s much easier to understand the program flow using PowerShell.

                      Regarding the startup time of PowerShell; I agree. It’s way too long to spin up a process when needed, but I just keep a terminal open at all times using ConEmu, so it’s always available at a hotkey.

                      Ultimately it’s up to you how you want to work. I just find CMD to be a difficult beast compared to POSH.

                      1. 2

                        So, when it gets to writing anythingore complicated than “start a program or two, maybe passing through some arguments”, then yeah, I prefer to write it in something other than batch. PowerShell works, currently I like Nim for that sort of thing.

                        This has proved a nice way to get quick responsiveness from a shell on Windows, and deal with complicated command invocations, without having to deal with the issues that mingw can have. As a bonus, you can get easy documentation for your uses cases of a particular command.

                    2. 1

                      What other systems use cmd apart from Windows?

                      (I realize DOS does)

                      1. 3

                        DOS uses COMMAND.COM, not CMD. CMD is used by ReactOS, OS/2, and Windows NT and later if I recall correctly. I get your point, but seriously using CMD is analogous to archaeology at this point…

              2. 3

                I do this for commands that I use (moderately to extremely) often.

                When it’s a command I’m not used to yet, the benefits is that I don’t have to relearn it and its parameter everytime. cat mybashfile.sh will show me the command to launch and the comments about the parameters, with an example I have already done.

                But in the case of the author however, with a command I call really often I’d be tempted also to use Control-R and edit the command on the CLI, or use history then use fc 499 to edit (in the defined text editor) the command to be relaunched (if the command is number 499 in the history output).

                They are only available on linux and OSes with bash though.

                1. 3

                  PowerShell does have the Ctrl + R functionality, so it might suit your usage better than using cmd (which is really only there for backwards compatability). POSH is feeling more and more similar to bash as time goes on IMO.

                  1. 2

                    Thanks for correcting me. I have stopped using powershell since I migrated totally to linux, but I agree with you that it made windows feels more comfortable.

                    1. 1

                      I get that. I feel like a POSH evangelical even though I use it rarely, but if a tiny tidbit of information like that can help someone then I feel it’s worth sharing it :)

                  2. 3

                    I use the up-arrow to only suggest history that starts with that I already typed, so ls<Up> only gives me results that start with ls. It’s not set by default, but it’s up-line-or-beginning-search in zsh, and history-search-backward in readline/bash.

                    I personally prefer that over <C-r> searching for various reasons. YMMV.

                  3. 2

                    You really should try Clink. It adds GNU Readline editing to cmd.exe and it’s great. Highly recommended.

                    1. 1

                      Thanks! I especially like the sound of being able to provide completion information via Lua.

                    2. 1

                      A command-line productivity boost I recently added was a commit script to my zsh config:

                      commit() {
                        git add -A :/ && git commit -m "$1" && git push

                      Being able to simple type commit 'Summary of changes' instead of

                      • typing git a
                      • tapping the up arrow to autocomplete the entire contents of commit script
                      • tapping the left arrow and then backspace/delete to replace the previous git message with an updated message

                      has made my life so much easier.

                      1. 3

                        git commit -a more or less does the same, although you’ll still need to add new files with git add (arguably a feature or annoyance). The downside of your approach is that it’s harder to write “good” commit messages with more context, since everything will always be on a single line.

                        1. 3

                          The downside of your approach is that it’s harder to write “good” commit messages with more context, since everything will always be on a single line.

                          Agree. Two useful bits of git to share:

                          1. if you do git commit -m "message" you can append as many more -m’s as you want to add lines to the commit message.

                          2. additionally (I only learned this recently), you can append -e to open the commit message in your editor. So, git commit -m "commit message" -e will open your editor with “commit message” at the start. It makes it easy to start a commit on the commandline and bail out to your editor to write more.

                          FWIW, here are similar aliases I use:

                          c = commit
                          cm = c -m
                          ca = c -a
                          cam = c -am
                          cmp  = "!f() { git cm \"$@\" && git p; }; f"
                          camp = "!f() { git cam \"$@\" && git p; }; f"

                          So, my git camp (commit all with message and push) is similar to u/netopwibby’s commit function, but it’s composable, and additional arguments to git can be provided.

                          (p is an alias that pushes, automatically setting the upstream if necessary.)

                        2. 3

                          A nice, tiny improvement to scripts like this is to use the ${var:?error message} pattern. I use that a lot where I write a script that has to have an argument that I might forget, and forgetting would break the whole thing, but also where doing the full if [ -z "$var" ]; then printf $'bad\n'; fi pattern is overly verbose.

                          commit() {
                            git add -A :/ && git commit -m "${1:?need commit message}" && git push
                          $ commit 'Summary of changes'
                          $ commit
                          -bash: 1: need commit message

                          You can also improve the interface just a little bit if you use "$*" instead of just "$*" (at the cost of weird characters sometimes messing things up if you don’t use quotes, like asterisks).

                          commit() {
                            git add -A :/ && git commit -m "${*:?need commit message}" && git push
                          $ commit 'Summary of changes'  # works like normal
                          $ commit Summary of changes  # also works
                          $ commit
                          -bash: *: need commit message
                          $ ls
                          bar  foo
                          $ commit Use * instead of 1  # same as commit 'Use bar foo instead of 1'
                          1. 1

                            Oh that’s nice, I’ll try it.

                        3. 1

                          I think this is kind of mixing together a couple of common needs.

                          1. Taking notes about how to do something you do infrequently but is difficult to remember, and may be somewhat specific to your particular work environment
                          2. Automating repetitive tasks that you do very frequently.

                          In your example:

                          REM Other useful argument combos
                          REM -tcs -tsql -Txml

                          This is kind of meaningless to me because I don’t use RipGrep. I would think that if for some reason you didn’t use this particular set of args for 6 or 7 months, that “useful argument combos” might not be that helpful to you either because it doesn’t actually tell you what it does or what it is for.

                          Based on my interpretation of your use case, I have a little advice for you.

                          • Keep well organized notes about how to do those complex but infrequent tasks. Write them as if you were writing them for someone else who had never done it before, because that extra detail might be helpful to you in the long-run.
                          • When you do really need to write a script to automate a task, do your best to write the script in a way that the script doesn’t need to be edited frequently. If you have to open up the script and edit it in order for it to be useful, its justification for existence is somewhat dubious. You could have just copy and pasted a sample command from your notes and edited it on the command-line instead.

                          Here is a relevant xkcd that you might find interesting, in case you haven’t seen it before:

                          xkcd: Is It Worth the Time?

                          1. 1

                            As much as anything else, it’s also making easy to switch between different arguments for a given command, without forcing me to come up with some arbitrary names for the different combinations of arguments

                            I didn’t add this as context in my post, but I have definitely explored up and down the scales of automating repetitive tasks, between building my own versions of things like a jumplist, and building various websites for my own use.

                            Not everything is worth documenting in large amounts of detail, but I do think it’s worth trying to point out the small gains for other people from time to time. A small amount of simplicity can go a long way.

                            You could have just copy and pasted a sample command from your notes and edited it on the command-line instead.

                            One advantage the approach I lined out in my post has is that with a shorter command to type, you’re not having to use a relatively clumsy CLI editor to move things around. This is less of a pain point on bash and unix for a number of reasons.

                            I’ll admit that this is far from my most polished blog article, and there are definitely cases where I don’t want to be editing a given script a lot. In my experience, I edit the 2 scripts I have set up with way 1-5 times a day when I’m using them, usually once to get it set up for the task I’m using it for, and then I process to use the script 10-50 times over the next hour or so. For me, anyway, the cost of creating a file and editing it far offsets the awkwardness of trying to get back to a given command in my history. But, for me, this is mostly a bit of an enhancement on a bash alias.

                          2. 1

                            I used to rely on stuff like history | grep, but now this problem is completely solved for me with fzf.

                            1. 1

                              Speaking of which, is there a way to make fzf’s Alt+c also search higher up directories or a reason not to do that?

                              1. 1

                                Not sure if there’s a grand philosophical reason, but I know I’d be annoyed if every search went through my entire file system. You could probably do this if you wanted to — perhaps with an alias and a subshell — but I like it the way it is.

                            2. 1

                              Cute. I’ve spent a years in the rabbit hole you are decorating.

                              1. 1

                                Could you explain more?

                                Part of why I use this technique is because I’ve found it helps me avoid falling too far down a rabbit hole. For me, it represents an 80/20 tradeoff. I’m trading off a little more effort in writing a script, to get an editable CLI shortcut for processes I repeat a lot.

                                It’s little things like this that I’ve been finding that make working at the command-line on Windows less painful for me.