Tab auto-completion removes quotes from variables even when it shouldn't
Bash Version: 4.4 Patch Level: 12 Release Status: release Tested also in the last version from this unofficial mirror: https://github.com/bminor/bash so I guess it's still a problem. Tab auto-completion removes quotes from variables even when it shouldn't. Test case: $ mkdir 'a b' $ touch 'a b'/c $ i='a b' $ ls "$i"/ After pressing tab, the last line becomes: $ ls $i/c When pressing enter, the expected result happens: ls: cannot access 'a': No such file or directory ls: cannot access 'b/c': No such file or directory I expected quoted variables to preserve the quotes when auto-completing with tab.
Problem with list of aliases
When using the 'alias' command without parameters, or with the '-p' parameter, a list of aliases is displayed. This list has the form: alias name='value' 'help alias' states that this form is 'reusable', thus implying, if I understand it correctly, that it can be fed back to bash. But that's not always the case. I have an alias called '-' that resolves to 'cd -'. This alias needs to be entered as follows: alias -- -='cd -' However, it is output by the 'alias' command as: alias -='cd -' And when that line is input to bash, it produces an error: bash: alias: -=: invalid option alias: usage: alias [-p] [name[=value] ... ] This can be easily fixed with sed to ensure the output is compatible with bash: alias -p | sed 's/^alias -/alias -- -/' Therefore, either the docs need to be fixed (by adding a caveat, perhaps suggesting the 'sed' workaround, or by omitting 'reusable'), or the output of 'alias -p' should include '--' when the alias name starts with '-'.
Sourcing a file ending in \newline disables aliases for 1 command
Bash Version: 4.2 Patch Level: 37 Release Status: release Description: If a file with a command that ends in \newline is sourced, the next command issued in the command line does not interpret aliases but subsequent ones do. It's a minor issue easy to work around, but since it's surprising behaviour and some aliases are important, I thought I'd report it. In the real case where I used it, the command was 'rm' which was an alias to 'rm -i' to ask for confirmation, and it didn't ask. Repeat-By: $ alias hi=echo\ hello $ echo /bin/true\\ testbug.sh $ hi hello $ source testbug.sh $ hi bash: hi: command not found $ hi hello
Sourcing a file ending in \newline disables aliases for 1 command
Bash Version: 4.2 Patch Level: 37 Release Status: release Description: If a file with a command that ends in \newline is sourced, the next command issued in the command line does not interpret aliases but subsequent ones do. It's a minor issue easy to work around, but since it's surprising behaviour and some aliases are important, I thought I'd report it. In the real case where I used it, the command was 'rm' which was an alias to 'rm -i' to ask for confirmation, and it didn't ask. Repeat-By: $ alias hi=echo\ hello $ echo /bin/true\\ testbug.sh $ hi hello $ source testbug.sh $ hi bash: hi: command not found $ hi hello
Re: Sourcing a file ending in \newline disables aliases for 1 command
John McKown wrote, On 2015-04-03 14:19: Note that testbug.sh does end in a LF, at least if I did it correctly. I've noticed that actually the LF is not important, only the final backslash is: $ alias hi=echo\ hello Without final LF: $ echo -n true\\ testbug.sh $ . testbug.sh $ hi bash: hi: command not found $ hi hello With final LF (same case as initially submitted): $ echo true\\ testbug.sh $ . testbug.sh $ hi bash: hi: command not found $ hi hello But if there is one more LF it doesn't reproduce: $ echo true\\ testbug.sh $ echo testbug.sh $ . testbug.sh $ hi hello In the first case the file is malformed, so that's not a problem. I think the second case should act as if the last command was in a line by itself without a terminating newline, but that's not what happens. It can also be argued that in that case the file is malformed too. In my real use case, the last lines were a set of options to which I was constantly adding or removing, with a backslash at the end of each line. At one point I wasn't careful and didn't remove the backslash from the last line. As I said, the next thing I did was to delete a file, and that's how I noticed it didn't prompt me for confirmation. I can easily add a ; in one line alone at the end of the file and insert the options before it. That'd work around this. Since testbug.sh terminates with a \, it appears that the BASH shell is seeing your second command as \hi. Which _appears to me_ is what BASH would call a quoted value. And it is documented that aliases are not expanded when quoted. On the other hand, this works as expected: $ echo true\\ testbug.sh $ . testbug.sh $ hi bash: hi: command not found My point with this last example is that it's not quoting the double quotes as if they were prefixed with a backslash. This is what happens when that's the case: $ \hi So it's not as simple as it acts as if preceded by a backslash. Also, it doesn't reproduce if the aliased command is inside the sourced file: $ echo true\\ testbug.sh $ echo hi testbug.sh $ . testbug.sh bash: truehi: command not found (which is expected). $ echo true\\ testbug.sh $ echo testbug.sh $ echo hi testbug.sh $ . testbug.sh hello (which is expected too).
