Conversation
|
I think you can just replace |
Which line are you referring to? |
Sorry about that, line number 544 in original file (line number 553 in the PR file). |
Oh thanks for mentioning this, I didn't notice that. |
|
I don't know why coreutils/src/uu/cut/src/cut.rs Lines 543 to 547 in 439b7e0 is there. This doesn't seem to be the behaviour of GNU's cut:
$ echo "--libdir=./out/lib" | gcut -f2 -d "" | hexdump -C
00000000 2d 2d 6c 69 62 64 69 72 3d 2e 2f 6f 75 74 2f 6c |--libdir=./out/l|
00000010 69 62 0a |ib.|
00000013
$ echo "--libdir=./out/lib" | hexdump -C
00000000 2d 2d 6c 69 62 64 69 72 3d 2e 2f 6f 75 74 2f 6c |--libdir=./out/l|
00000010 69 62 0a |ib.|
00000013 |
|
Nice! The only difference with GNU I can still find is: But I guess that's not useful anyway. |
|
I noticed that I tried these commands in my zsh (ArchLinux): $ echo 'ab\0cd' | cut -f 1,2 -d '' --output-delimiter=Z | hexdump -C
00000000 61 62 5a 63 64 0a |abZcd.|
00000006
$ echo 'ab\0cd' | uu-cut -f 1,2 -d '' --output-delimiter=Z | hexdump -C
00000000 61 62 00 63 64 0a |ab.cd.|
0000000Using coreutils/src/uu/cut/src/cut.rs Line 544 in 439b7e0 And this line cannot be execute in any situation! |
fix for #2424
GNU's
cutsupports-d=to set the delimiter to=.Clap parsing is limited in this situation, see.
Since clap parsing handles
-d=as delimiter explicitly set to""we can use this as basis for a simple workaround.The downside is that
uu_cutloses the ability to handle empty delimiters.I don't know how often this is used, or if it is useful at all, but I consider this an acceptable tradeoff.
GNU's behaviour for an empty delimiter is to echo the input.
Other alternatives for a workaround to fix #2424 could be:
argsbefore callingApp::get_matches()Arg::with_name(options::DELIMITER).empty_values(false)useApp::get_matches_safe(), handle the error manually and set the delimiter to=