handle flag in a sensible manner about myaliases HOT 6 CLOSED

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.)

from myaliases.

@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.

from myaliases.

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.

from myaliases.

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.

from myaliases.

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

from myaliases.

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?

from myaliases.