Bash: how to avoid a command inside an alias being used as another alias?

dedec0 · 12-10-2017, 09:34 AM

Quote:

Originally Posted by rknichols

It gets very messy, especially with all the special cases of backslash within double quotes. And, tab completion does not respect wildcards -- all the preceding characters in the word are taken literally.

It is not messy. It is contradictory, and that is bad. See my previous post.

dedec0 · 12-10-2017, 09:38 AM

Quote:

Originally Posted by pan64

if you want to understand bash probably you can use set -x:

Code:

user@host:/tmp$ touch *asd*    # << this is what you entered
+ touch '*asd*'                # << this is what was execcuted after evaluation of command line

I did not know about that option. I will examine its consequences later. Hope you have seen my new-question post.

pan64 · 12-10-2017, 10:02 AM

Quote:

Originally Posted by dedec0

Code:

$  touch "9asd*lkj"; ll
9asd*lkj

$  touch "9asda*lkj"; ll
9asda*lkj
9asd*lkj

$  # Before pressing enter for the next command, I tried to expand the argument.
$  rm 9asd*lkj

The argument to rm, as shown, is expanded to one of the two choices it had! It expands to "9asda\*lkj" - without the quotes, plus a space that possibly expected an argument. We normally conclude that the *only* possible file was found, then - at least me. Wouldn't you?

This is the real story: that expression is expanded to all the files matching.

Code:

user@host:/tmp/a$ touch "9asd*lkj"
user@host:/tmp/a$ touch "9asda*lkj"
user@host:/tmp/a$ set -x
user@host:/tmp/a$ rm 9asd*lkj
+ rm '9asda*lkj' '9asd*lkj'

Quote:

Originally Posted by dedec0

Do you consider this a bug in Bash? I do, but I would like to see more opinions in this.

No, this is how it really should work.

dedec0 · 12-10-2017, 10:26 AM

Quote:

Originally Posted by pan64

This is the real story: that expression is expanded to all the files matching.

Code:

user@host:/tmp/a$ touch "9asd*lkj"
user@host:/tmp/a$ touch "9asda*lkj"
user@host:/tmp/a$ set -x
user@host:/tmp/a$ rm 9asd*lkj
+ rm '9asda*lkj' '9asd*lkj'

No, this is how it really should work.

I expected (and think it is good and reasonable to do so) that a lkj*jkl argument should mean:

All files that start with lkj, have something or nothing in the middle, and ends with jkl. Not a literal * in it, being one word only!

/-:

pan64 · 12-10-2017, 10:54 AM

Quote:

Originally Posted by dedec0

I expected (and think it is good and reasonable to do so) that a lkj*jkl argument should mean:

All files that start with lkj, have something or nothing in the middle, and ends with jkl.

This part is ok.

Quote:

Originally Posted by dedec0

Not a literal * in it, being one word only!

Why not? As you told: have something or nothing in the middle (= including really anything, including even a * - or more...)

dedec0 · 12-10-2017, 11:47 AM

Quote:

Originally Posted by pan64

Quote:

Originally Posted by dedec0 View Post
I expected (and think it is good and reasonable to do so) that a lkj*jkl argument should mean:

All files that start with lkj, have something or nothing in the middle, and ends with jkl.

This part is ok.

Quote:

Originally Posted by pan64

Quote:

Originally Posted by dedec0 View Post
Not a literal * in it, being one word only!
Why not? As you told: have something or nothing in the middle (= including really anything, including even a * - or more...)

Why not? As you told: have something or nothing in the middle (= including really anything, including even a * - or more...)

Because the line rm in the following command set removes two files, not only one:

Code:

$  touch "9asd*lkj"; ll
9asd*lkj

$  touch "9asda*lkj"; ll
9asda*lkj
9asd*lkj

$  rm 9asd*lkj
removido '9asda*lkj'
removido '9asd*lkj'

$

But if we press tab (instead of enter) after we type the last J, the argument is expanded to one of 2 possible files that exist in the expression given to the expansion routine. That is contradictory! That expansion should not happen! Both should be shown to me as these lines are showed if I press "ls" followed by tab:

Code:

ls           lsattr       lscpu        lsipc        lsmod        
lspci        lsusb        ls1          lsblk        lsd
lsram        lslocks      lsns         lspgpot      lsof              
lsar         lsb_release  lsinitramfs  lslogins

rknichols · 12-10-2017, 12:01 PM

As I said in #13, tab completion does not expand wildcards. It takes all the characters literally. If there had been no file with a literal "*" in that character position, tab completion would have failed and given you a "beep" in reponse.

As for use of the words "escaping" vs. "quoting", quoting causes characters within the quotes to be taken literally, removing their special meaning. A backslash removes any special meaning of the character that follows it, and is thus a form of quoting. But, I don't wish to stand in the way of your continuing to find that contradictory or confusing.

pan64 · 12-10-2017, 12:32 PM

yes, tab and * are two different things, do not mix them. they are not working the same way, they have different purposes, different implementations, but also they have some (occasional) similarities.

dedec0 · 12-11-2017, 07:38 AM

@rknichols: It has nothing to do with "standing in the way" of nothing. I just do not see that thinking it is good or reasonable. I think there is an issue in this matter.

Quote:

Originally Posted by pan64

yes, tab and * are two different things, do not mix them. they are not working the same way, they have different purposes, different implementations, but also they have some (occasional) similarities.

Mixing them is rare, but I see no problem with the possibility of having one * anywhere in a string to be tested + expanded + results showed (with a second tab). For more than one * in the same string, is will not be possible (or feasible, I do not know if it is) if there is no match for all of them being empty.

pan64 · 12-11-2017, 08:22 AM

Quote:

Originally Posted by dedec0

I see no problem with the possibility of having one * anywhere in a string to be tested + expanded + results showed (with a second tab)

This is what I tried to explain: you can see no problem, but this is not the way how it was designed/implemented. If you wish that behavior you need to implement that for yourself.

dedec0 · 12-11-2017, 10:20 AM

Quote:

Originally Posted by pan64

This is what I tried to explain: you can see no problem, but this is not the way how it was designed/implemented. If you wish that behavior you need to implement that for yourself.

Ok. Thank you for explaining it a bit more.