arielf / cuts Goto Github PK

Currently, these ranges (e.g. 2--1) are implemented as wrap-arounds (going right to left) because they are interpreted as 'reverse order' ranges.

It would be nicer if we could support a straight (left to right) expansion of them.

The problem is that the number of fields is not known till actually reading each line, so expand_list() should be lazily delayed till parse time, and on each line which is incompatible with the current implementation.

This is the only case out of 4 which is not 'natural'. the other 3 cases: positive-positive, negative-negative, and negative-positive are all implemented as might be reasonably and optimally expected by the user.

The option ambiguity detector which inserts -- between cuts options and ambiguous args (args starting with- like stdin and negative offsets) fails to work in some edge cases. It needs another adjustment to skip option-args e.g.:

$ cuts -d regex -1 file
Unknown option: 1
...

Thank you! It's awesome to be able to stop futzing around with variable numbers of spaces.

What I found is that when you're accustomed to using 'cut' with cron, and programs run by cron, it's really easy to forget that 'cuts' is an external program and so requires the full path even when used together with cut. For example, this worked in cron:

=ps x | grep <Blah>| grep -v grep | /usr/local/bin/cuts -3 | cut -d'\' -f1 | cut -d'_' -f2

where

=ps x | grep <Blah>| grep -v grep | cuts -3 | cut -d'\' -f1 | cut -d'_' -f2

gave me a blank variable even though the program worked fine from the command line.

I scratched my head for an embarrassingly long time figuring out I'd left off the path.

Thanks again.

Very nice utility, thank you!

Would be nice to have support for stuff like:

cuts 3-6
cuts 1-2,7,10

Or even ranges allowing negative offsets:

cuts 4--2

Sorry if I am missing something really basic. But here's the use-case. Right now I really want to diff two files and my diff is showing me something weird, so I wanted to diff their hexdumps.

Initially diff <(xxd file1) <(xxd file2) was a good start. However the problem here was the offset column. My diff is actually a special diff that can handle newlines (it is character-wise diff), so all I am missing now is to just remove the first column of xxd's output. I thought, hey that new cuts util I grabbed is perfect for the job!

I couldn't come up with a good way to do this at first.

xxd index.php | cuts -d':' -1

Doesn't work; the file contains colons inside it so some lines are missing a bunch of data due to the last "column" being problematic because it can have all manner of ASCII content in it.

xxd index.php | cuts 1--1

I was hoping it would detect space as the delimiter (which it does!!) and give me the columns ranging from 1 thru minus 1 (which means cols 1 thru the last, which means just remove the first column). This does not work and produces what appears to be the output representing column 1, then column 0, then column -1. This is almost certainly a bug.

Then I tried this:

xxd index.php | cuts 1-99

This is an attempt to hack the last thing I tried, and it comes closer. However, the columns are re-printed separated by what appear to be tabs. Two points to make here. (1) I think it would make the most sense to exactly replicate the delimiter on output. I shouldn't have to use -D. (2) -D adds delimiters for the columns specified. Since I used 99 columns there are now exactly 98 spaces in the output... This is just a consequence of my hack.

I basically had to give up on the column selection syntax and went for this solution using regex:

xxd index.php | cuts -d'^[a-f0-9]+:' 1

The conclusion is that cuts is remarkably powerful primarily because of the regex capability. However for less brain power consumption, I think the column index specification syntax can be improved.

I understand that even though the scope of this utility is rather narrow on paper, it embeds a whole crap load of complexity in the edge-cases. So take your time to get this whole thing sorted... Thanks for implementing the regexes, though, it's plenty useful to have that and the built-in paste capability.

Hi,

Perhaps I am misunderstanding how the cuts function works, but according to the documentation if one was to do this:

cuts f1 0 -1 f2

Should lead to 1st & last columns from f1 & last column (last colno seen) from f2.

But given these test data:

f1

a 10
b 12
c 14

f2

i 1
ii 2
iii 3

cuts f1 0 -1 f2

Produces

a 1
b 2
c 3

I thought it would produce

a 10 1
b 12 2
c 14 3

Is this expected? Or a bug?

how to make cuts 1 index column 1 in stdin when file 1 is present?

$ touch 1
$ echo "a  b c" | cuts 1
<empty>

cuts :1 cuts - 1 do not work, nor does cuts /dev/stdin 1
PS actually worse: cuts - 1 gives answer "a" (expected "b"), I don't understand why