File names with shell-special characters

[jylertones]

In my repository, I have files with names like "$list.xml." When I use "ga" to add those, it does not escape these characters.

$  gs
# On branch: scratch/test  |  [*] => $e*
#
➤ Changes not staged for commit
#
#       modified: [1] $list.xml
#
$  ga 1
fatal: pathspec '/Users/username/git/test/.xml' did not match any files
# Added '/Users/username/git/test/$list.xml'

If there's anything I can do to help fix this bug, please let me know. Thanks in advance!

[HaleTom]

The mv alias also fails:

% type mv
mv is an alias for exec_scmb_expand_args /usr/bin/mv
% mv '$moo' '$cow'      
/usr/bin/mv: missing file operand
Try '/usr/bin/mv --help' for more information.
% /usr/bin/mv '$moo' '$cow'
% 

As can be seen above, /bin/mv works ok.

[ghthor]

Yep, that makes sense. We need to add a map over the expansion list to sense and escape these values. I'll try to dig into this a little and post back what I find out.

[HaleTom]

@ghthor I've already implemented a fix with arrays and built in shell quoting.

Just putting the final touches on it now.

Ping me if you've not heard in a week.

[ghthor]

Hell yeah! Reminder is set =)

On Fri, Aug 24, 2018 at 11:37 AM Tom Hale notifications@github.com wrote:

@ghthor https://github.com/ghthor I've already implemented a fix with arrays and built in shell quoting.

Just putting the final touches on it now.

Ping me if you've not heard in a week.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scmbreeze/scm_breeze/issues/204#issuecomment-415797074, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJyKviRlOWnvZ0YdAEMmzWH7JV61saZks5uUB23gaJpZM4IIlmZ .

[HaleTom]

Work so far: https://github.com/HaleTom/scm_breeze/tree/quote-filenames

I've made good progress cleaning up a bunch of things. The snag I've hit is that the processing of ls output.

I'm currently considering running ls twice - once with QUOTING_STYLE= unset to have a raw filename output, and once with the user's set value of QUOTING_STYLE to display in their preferred way. #255 relates.

There is a race condition here though - it's possible that the directory contents change between invocations of ls.

The other option is to get \0 terminated filenames from find, and then call ls on those filenames in that order, but that would require differentiating ls options from the filenames to list in the case of ll -t --long-option -- file1 file2

Thoughts?

[ghthor]

Using find as the source of truth for the files seems like it would be the most correct. ls already has the requirement that the options come first, aka ls [OPTION]... [FILE]... so separating the arguments from the file targets should be straightforward.

Having said that, I'm happy with either. Handling that race condition should be pretty straightforward, just take a union of the the 2 sets. It's not perfect, but it will suffice, if performing the union is easier then implementing the version using find.

[HaleTom]

Please check #263 and confirm if this is resolved.