Note that when called without arguments, this yields the value of $0, which may not be what’s intended.

My go-to way of quickly parsing arguments is as follows:

#!/bin/bash                                                                  
                                                                             
quiet="true"                                                                 
files=()                                                                     
                                                                             
for arg in "${@}"; do                                                        
    case "${arg}" in                                                         
        "-v" | "--verbose")                                                  
            quiet="false"                                                    
            ;;                                                               
        *)
            files+=(                                                         
                "${arg}"                                                     
            )                                                                   
            ;;                                                               
    esac                                                                     
done                                                                         

Beautysh (v6.1.0) incorrectly reports this as indent/outdent mismatch and instead indents it like so:

#!/bin/bash                                                                  
                                                                             
quiet="true"                                                                 
files=()                                                                     
                                                                             
for arg in "${@}"; do                                                        
    case "${arg}" in                                                         
        "-v" | "--verbose")                                                  
            quiet="false"                                                    
            ;;                                                               
        *)                                                                   
            files+=(                                                         
                "${arg}"                                                     
            )                                                                
                ;;                                                           
        esac                                                                 
    done

The deciding factor seems to be the multi-line parenthesis in assigning files. If I assign it all on one line, like this:

            files+=("${arg}")                                                

then beautysh is satisfied with the indentation (i.e. doesn’t change it or report a mismatch).

1.37.0 fails to build in my build environment (Ubuntu 18.04 in LXC) with this error:

ubuntu@mattermost-mobile:~/mattermost-mobile$ npm run build:android

> mattermost-mobile@1.37.0 build:android /home/ubuntu/mattermost-mobile
> ./scripts/build.sh apk

./scripts/build.sh: 3: ./scripts/build.sh: Syntax error: "(" unexpected
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! mattermost-mobile@1.37.0 build:android: `./scripts/build.sh apk`
npm ERR! Exit status 2
npm ERR! 
npm ERR! Failed at the mattermost-mobile@1.37.0 build:android script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/ubuntu/.npm/_logs/2020-11-14T11_47_00_288Z-debug.log

The top of that file, build.sh, refers to /bin/sh, but on Ubuntu and Debian, /bin/sh has been Dash for quite a while, whereas build.sh seems to written for Bash (where function is a valid keyword):

ubuntu@mattermost-mobile:~/mattermost-mobile$ head scripts/build.sh 
#!/bin/sh

function execute() {
    cd fastlane && NODE_ENV=production bundle exec fastlane $1 $2
}

I suggest switching the shebang to #/bin/bash, or better yet, #!/usr/bin/env bash (for path-agnosticity). In my environment, using either one fixes the build.

This doesn’t work with hidden files in Bash, unless you shopt -s dotglob first.

@Gilles’SO-stopbeingevil’ Ok, it was just my misunderstanding then; I interpreted the quote as meaning ”you should quote RHS regular expressions”.

”Except that you do need double quotes where a pattern or regular expression is expected: on the right-hand side of = or == or != or =~.” Perhaps I’m misunderstanding this, but AFAIK, a RHS regular expression (i.e. after =~) should always be unquoted (since Bash 3.2 at least).

`[ ”$c” != ”” ]` is `false` for completely empty files which is contrary to what I’d expect.

I’m in a UTF-8 environment and a lot of my directories’ names have characters above ASCII in them. For many of those it’d be natural to assign bookmark names that also have characters beyond ASCII. For example, my ”Desktop” directory is localized as ~/Työpöytä, and I’d like to name that bookmark ”työpöytä”.

jani@saegusa:Työpöytä$ s työpöytä
bookmark name is not valid

This fails because bashmarks validates names using the regexp /[^A-Za-z0-9_]/. It’s simple enough to patch to account for the 6 additional characters in my Scandinavian locale, but bashmarks also derives an environment variable name from the bookmark name, and apparently Bash does not support UTF-8 for those:

jani@saegusa:~$ LC_MESSAGES=C export DIR_työpöytä=$HOME/Työpöytä/
bash: export: `DIR_työpöytä=/home/jani/Työpöytä/': not a valid identifier

There may be other obstacles as well, those are just the two I could find at a glance.

Obviously I can work around this by not using UTF-8 in bookmark names, but it needlessly increases the mental effort required to recall the names and also the chances of name collisions.

It’s not the same as #590829 after all: despite the similarities, the recipe given at #590829 does not reproduce the issue for me.

Tab completion of directory paths containing single quotes is broken like so:

$ mkdir -p ”a’b/c”
$ cd a\’b/ # pressing tab won’t complete the ’c’ dir

as opposed to:

$ mkdir -p ”de/f”
$ cd de/ # pressing tab here completes the ’f’ dir just fine, to ’de/f/’

I initially thought this was Bug #1485777, but the reason I’m not so sure anymore is that for me, a manually appended \’ does not disappear (unlike for the reporter of #1485777). This does however also seem like a regression back to the issue of Bug #590829.