Linux bash changes to how defaults to missing arguments are provided

markfinal's Avatar


15 Jun, 2019 04:50 PM


I've noticed a change in the behaviour on the Ubuntu images in the last day or so.

In shell scripts I have, I rely on being able to optionally provide an argument, and specify a default value if it is not provided, i.e. this syntax for whether the first argument is provided or not.


This has been working for a long time.
However, just recently, instead of getting the default value, I get this kind of expression:


Here's a simple reproducible:

Has anything changed on the Ubuntu images to cause this?


  1. Support Staff 1 Posted by Feodor Fitsner on 15 Jun, 2019 10:09 PM

    Feodor Fitsner's Avatar

    Hi Mark,

    Could you please provide more compete repro? Like a simple build in a public repository would be awesome.

    Thank you!

  2. 2 Posted by markfinal on 16 Jun, 2019 06:00 AM

    markfinal's Avatar


    Here's the github repo I used for the reproducible I linked to


  3. 3 Posted by markfinal on 17 Jun, 2019 07:25 PM

    markfinal's Avatar

    FYI I just tried the alternative syntax for default argument values, i.e. both of these forms:


    and I'm still getting the shell-<hash> result in both cases when there is no argument.

    See and

  4. Support Staff 4 Posted by Wasa Pleshakov on 17 Jun, 2019 08:20 PM

    Wasa Pleshakov's Avatar

    Mark, this is very interesting issue, we will investigate it for sure. But meanwhile can you please test it with image "Previous Ubuntu1804“ to make sure that this caused by recent update of images

  5. 5 Posted by markfinal on 17 Jun, 2019 08:32 PM

    markfinal's Avatar
  6. 6 Posted by markfinal on 17 Jun, 2019 08:47 PM

    markfinal's Avatar

    Update: I've just noticed the same behaviour can be reproduced on the Ubuntu1604 images!

  7. Support Staff 7 Posted by Wasa Pleshakov on 19 Jun, 2019 07:57 AM

    Wasa Pleshakov's Avatar

    It appears only if you source script. Is there any particular reason to source it instead of running in subshell? like this:

    chmod a+x
  8. 8 Posted by markfinal on 19 Jun, 2019 08:10 AM

    markfinal's Avatar

    For my actual repos, I use source in order to modify the existing shell, as I then run more commands using the modifications, i.e.

    source && <run command using modified environment>

  9. Support Staff 9 Posted by Wasa Pleshakov on 19 Jun, 2019 08:11 AM

    Wasa Pleshakov's Avatar

    So basically you're getting a value of the first argument of the shell we run all appveyor commands in.
    If there is no way to run your script in subshell then you can just add shift at the begging of your appveyor.yml:

      - sh: shift
    or anywhere before sourcing

    Anyway this is a bug and we will fix this on next images update.

  10. Support Staff 10 Posted by Wasa Pleshakov on 19 Jun, 2019 04:42 PM

    Wasa Pleshakov's Avatar

    Hey Mark,
    did shift hackery helped you to resolve the issue?

  11. 11 Posted by markfinal on 19 Jun, 2019 06:07 PM

    markfinal's Avatar


    I just gave it a try, and yes for the Ubuntu1804 image, using shift first does resolve the issue.
    Unsurprisingly, if I use it in 'Previous Ubuntu1804' I get an error.

    Since you've said the bug will be fixed in the next images update, I'm content to use the Previous UbuntuXYZ images until they are released, as I'm not reliant on any of the absolute latest software.

    Thanks for looking into this,

  12. Support Staff 12 Posted by Wasa Pleshakov on 19 Jun, 2019 11:23 PM

    Wasa Pleshakov's Avatar

    If you need this workaround to work in all current and previous Ubuntus you can wrap it in simple if clause:
    if [[ -n "$1" ]];then shift; fi

  13. Ilya Finkelshteyn closed this discussion on 20 Aug, 2019 09:01 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac