Closed ale5000-git closed 3 weeks ago
The shell globbing code follows POSIX conventions and only looks for '/' as a directory separator. Backslashes are accepted in parts of the path that don't have any patterns.
The same is true of tab completion.
Ok. thanks.
The shell globbing code follows POSIX conventions and only looks for '/' as a directory separator. Backslashes are accepted in parts of the path that don't have any patterns.
The same is true of tab completion.
Unclear to me whether you think the w32 version should accept \
in this case (it might still not be worth fixing, e.g. if it's too hard, but at least specify what it should do).
FWIW, I think it should, because globbing is very closely tied to path interpretation, and if path interprets \
as separator on windows, then I don't think it should prevent globbing (or tab completion).
If busybox got started with -X
, then using an env var to do the globbing will break.
For example JAVA_HOME on my system end in backslash on my system.
closed this as not planned
Why did you close it as not-planned? I don't see any hint for that in the reply.
It only explains why the bug happens. It doesn't say that it's not a bug or that it's not planned.
I think you should reopen it.
The first responsibility of the shell in busybox-w32 is to implement correct handling of backslash as an escape character.
This makes the use of backslash as a directory separator in Windows problematic, both for the user and the implementation.
I don't at present have any plan to make changes in this area.
The first responsibility of the shell in busybox-w32 is to implement correct handling of backslash as an escape character.
Sure. Agreed.
This makes the use of backslash as a directory separator in Windows problematic, both for the user and the implementation.
I don't yet see why, or how it's related to the escape comment above.
in bb-w32 $PATH
rightly allows backslash in paths, execution rightly also allows it, files in unix (but not windows) are allowed to contain literal backslashes, and, if quoted correctly, should not be interpreted as an escape while globbing.
Shouldn't fixing it be as simple as checking also \
where the glob implementation checks /
? (famous last words)
Alternatively, maybe globbing should first convert backslashes to slashes? (and if one wants to be cute, also restore converted backslashes at the result, but it's probably not worth the effort, and it can become complex quickly)
Inside single quotes the backslash should be treated literally but why this work:
ls -1 -d -- '.\my_dir/'*
but this does NOT work?ls -1 -d -- '.\my_dir\'*