The bash book to rule them all

Interesting, is there a source for this? Genuinely interested, because the manpage leaves this part a bit vague:

    A login shell is one whose first character of argument zero is a -, or
    one started with the --login option.
    (...)
    Bash attempts to determine when it is being run with its standard input
    connected to a network connection, as when  executed  by the historical
    remote shell daemon, usually rshd, or the secure shell daemon sshd.
    If bash determines it is being run non-interactively in this fashion, it
    reads and executes commands  from  ~/.bashrc, if  that file exists
    and is readable.

    After  this,  the client either requests an interactive shell or
    execution of a non-interactive command

> IIRC nope: distros such as Debian often have bashrc source bash profile

Well, these are distro dependent things. Since I am not on Debian, I am just refering to the manpage.

From the manpage:

     An interactive shell is one started without non-option arguments
     (unless -s is specified) and without  the  -c option,  whose  standard
     input and error are both connected to terminals (as determined by
     isatty(3)), or one started with the -i option.

I use LLMs for the latter, and they often do a great job and save a lot of time looking up individual flags, concepts, etc.

Anyone who does that now would already have done it from random Google results anyway.

Or `chown -r` or was it.. `chown -R`

The substance of the first answer:

    #!/bin/bash
    
    # Check if the first parameter is not provided
    if [ -z "$1" ]; then
        echo "Error: Parameter not provided."
        exit 1
    fi

> This checks if the first parameter (`$1`) is empty.

But what happened to the supplied task? It was stated and echoed as:

> Anonymous: ...if it's not passed?

> ChatGPT: ...if a specific parameter is not passed...

> ChatGPT: ...if the parameter is set.

The second answer:

    #!/bin/bash
    : ${1?"Error: Parameter not provided"}

> ...and the `${1?...}` part checks if the first positional parameter (`$1`) is unset or null.

--

(the most succinct possible idiom is `#!/bin/bash -u`)

You need to fully understand man before reading the man bash page. Here:

https://man7.org/linux/man-pages/man1/man.1.html

but before that are you reading that on chrome? Have you read the chrome documentation?

The Get-Help command is super useful, with the option to show examples (-Examples).

Consistency is encouraged because every PowerShell command is the combination of a verb and a noun. The verbs are standardised and you can get a list of supported verbs using Get-Verb. Nouns are free to choose.

There is also Get-Command which gives you a list of available commands in your current shell. You can import modules in the shell which will give you access to extra commands. Get-Command supports the parameters Module, Verb and Noun to filter commands. This allows you to fairly easily discover commands that might be usefull to you.

The Get-Alias command will show you what aliases are defined in your shell. This can sometimes be confusing as some of the default aliases look like Linux/UNIX shell commands.

Creating a PowerShell module is also not that hard. When defining a PowerShell command, it is for example very easy to limit the values for a certain parameter and that in turn hooks in into the completion functionality. The completion functionality is available out-of-the-box for every PowerShell command available, including the ones that you create yourself.

My main OS is Linux, but I do work a lot with Windows systems (I develop in C#). I've used bash a lot, but I also learned PowerShell because that is simply the way to go on Windows systems. I like PowerShell, it has a lot of nice features and it is easy to work with. I find it a lot easier to program extra functionality in a PowerShell module compared to defining extra functions in bash. As a C# developer, PowerShell basically also gives me access to any C# class available by default in .NET. It is even simple to load a class from a third-party assembly, and even to compile C# code on the fly. In short, I can do whatever I want in PowerShell a lot easier than in Bash.

Note that that does not mean that I no longer use Bash. It depends. My default shell on linux is bash. When I need a one-liner to do something, I will first reach for bash. It is only when I need a longer script that I will reach for PowerShell. For example, I need to read a json file, manipulate the json structures and write the data back out. That is something I would do in PowerShell. For a build script that is simply a sequence of steps, I would go for bash, even if it involves the use of jq for json for example. And obviously on Windows, my default shell is PowerShell. Even though I have used cygwin/ming before, I would not do that if I can avoid it... there is really no need to try to run bash or anything else on Windows when you have PowerShell.

pwsh reinforces pretty much the same* thing every time it's used, the more you learn the more you can do with every command, even ones you haven't used yet.

same subject to some base-level provided by the module. i.e. the active directory cmdlets have their own dsl inside -filter because it is a different thing. It's very analogous to `a = sql.cmd('SELECT ...').map(etc...)`. you can, you shouldn't, but maybe its fine. It's up to you.

"Runs somewhere" and "Is useful there" are two very different things.

> Verbosity can increase readability.

And usually it hinders readability. If anyone disagrees, he may explain how enterprise Java is more readable than Python, Go or Rust code. And yes, I do consider Rust more readable than Enterprise Java.

And that's when we talk about PROGRAMMING LANGUAGES. We are, however, talking about SHELL LANGUAGES. Other than most PLs, shells are in fact written more than they are read, so yes, "typeability" and terseness is a feature in shells, not a problem. And before anyone says "autocomplete": If a shell requires autocomplete to be somewhat useable, I will look for another shell.

> You will not loose those tools and their man pages when using PowerShell.

Did I say I will? That line was in reply to the statement that "the help system is categorically better", a statement I happen to disagree with.

> He is referring to the documentation of all helper functions defined within PowerShell.

And I am refering to the documentation that is defined within the shell environment on *NIX terminals.

> When you create a helper function in Bash, how do you document it and what tool can you use to consult that documentation?

Off the top of my head:

    - I can embed a `-h --help` flag directly in the script
    - I can write a manpage and use it via `man NAME`
    - A manpage is also discoverable by the `apropos` program
    - If it's a builtin I can use bashs builtin `help PATTERN`
    - I can write an entry for the `info` program

> Bash does not have named parameters for its functions, let alone metadata on them…

Which would truly be a bummer if bash needed named parameters. Since it doesn't, I don't see why this would be an advantage. If I want named params for a shell script, I can write it in python.