handle flag in a sensible manner

[GiselleSerate]

From commit 3005b00b3f5fb6fb636fae05b873cde19c72f1c8. Thanks, Arya.

---

Also, if this method of parsing the -s flag doesn't work or gets too complicated, there's also this:

while getopts "s" opt; do
    case ${opt} in
        s) local there_was_an_s="true"; shift;;
    esac
done

which will create the boolean there_was_an_s if the -s flag was included. You can use it later by creating an if-statement, like so:

if [ -n there_was_an_s ]; then
    # code that happens if the -s flag is specified
else
    # code that happens when the -s flag isn't specified
fi

That if-statement just checks whether the boolean variable exists.

[GiselleSerate]

If you handle the flag like this, you'll have to figure out how to get the nickname only without the flag preceding it when you try to grep within $current. For example, if you wrote addalias -s lp="commands" you want to grep for alias lp= to see if it exists, not alias -s lp=. (It's handleable with regex, but you just have to handle it.)

[aryarm]

@GiselleSerate, I might be wrong about this, but I think you can just use $1 to get lp="commands". You won't have to parse the entire command, and hence, you won't have to deal with the -s only sometimes existing.

[GiselleSerate]

That was my first thought, but I think it breaks over spaces, or that was my problem when trying to use numerical arguments even without trying to handle the option.

[aryarm]

Unless you're doing that because you want to preserve quotes. Actually, have you ever tried using single quotes instead of double? Ex: alias lp='commands'? I think that might solve the quotes problem.

[GiselleSerate]

Except that requires the user to type it in that way, and I'm pretty sure the normal alias command lets you use double

[aryarm]

So I tried to do some experiments with quoting. Take a look at this: This question and this question seem to explain why this happens. To summarize, when a command is executed, bash first evaluates the line that the user typed according to its normal rules. Part of this evaluation includes removing quotes from the parameters, and in the case of double quotes, bash also does some sort of evaluation of the content of the string inside the double quotes such that variables are converted to their actual values (as seen above). In the case of single quotes, the content of the string inside the quotes is interpreted literally.

So it seems clear that single quotes perform differently than double quotes. But what does this have to do with us, as writers of functions that take parameters that may be double or single quoted? Well, I think it explains that quoting of parameters is a tool of the user, and not something that we should ever handle or deal with. If the user chooses to use single quotes, it's because they want our function to get the literal string that they typed. Likewise, if the user chooses to use double quotes, it's because they want our function to get an evaluated version of their string. From this stack overflow answer, it seems that this is indeed what happens with the original alias command. I think this also shows that most of the time the user will likely want to use single quotes, not double quotes, when calling alias.

So if your alias command was to use "$1", I don't think it would ever have to deal with spaces. I'm still not sure why you were seeing numerical arguments break over spaces, but it could have been that $1 wasn't surrounded by double quotes in your function?