Hi, Ken.
I hadn't considered extending the cut reordering feature to bytes and
characters, too. I'm not opposed to it. My interest is only in delimited
fields. If it turns out to be trivial to apply reordering to the other two
selector types, then I guess it should be done.
I don't like the environment variable suggestion, though. It doesn't feel
like a good idea, but I can't articulate why. I guess it's mostly because
cut doesn't already use environment variables in any way. The
implementation would be more complex if env. var. support were a
requirement, whereas I believe the reordering feature is a (hopefully
somewhat simple) modification of cut's current functionality. Eric Blake's
suggestion to avoid variable conflicts also seems like a good reason not to
support env. var.
When I was first thinking about this feature, I was trying to decide
whether I'd like to add a new "-F" field selector option or a new "-o"
option to specify that the order of the field specification is
significant. I decided that "-F" wouldn't be good, because existing usage
of cut would need to put it in place of the "-f" option. However, "-o"
would be an additional option that could be specified programmatically.
Maybe like:
orderedOption=$(cut -f1 -o 2> /dev/null <<< '-o') # set "-o" option only if
it works
cut -d' ' -f4,1,3,2 ${orderedOption} <<< 'another hacker GNU just' # "just
another GNU hacker" if "-o" available
I'd also thought that by adding the "-o" option, in addition to working
with the "-f" option, it could work with "-b" and "-c" as well.
On 19 July 2017 at 09:29, Nellis, Kenneth <kenneth.nel...@conduent.com>
wrote:
> From: Steeve McCauley
> > I can't believe I'd never thought of reordering output columns like
> this.
> > FWIW, I agree that another option should be used to prevent issues with
> backward compatibility.
> >
> > $ echo 1,2,3,4,5,6 | cut -d, -f3,5,2
> > 2,3,5
> >
> > $ echo 1,2,3,4,5,6 | cut -d, -f3,5,2 -o
> > 3,5,2
> > Should this be extended to character output as well?
> > echo output | cut -c6,4,2 -o
> > tpu
> >
>
> Absolutely! It would be expected behavior (IMHO). I see no reason not to.
>
> In addition, so that scripts can work across platforms, I (strongly)
> recommend
> that a cut-specific environment variable be defined to allow specifying the
> field ordering behavior. In that way my QNX 4 script (whose cut would balk
> at
> the -o option) would work with Gnu. One possibility:
>
> CUT_OPTIONS=-o
>
> --Ken Nellis
>
