Trouble piping

[vefatica]

I have strings like these (with the leading spaces) in the clipboard.

            "purple": "#800080",
            "red": "#800000",
            "white": "#C0C0C0",
            "yellow": "#808000"

This works.

v:\> type clip: | cut -d "\"" -f4
#800080
#800000
#C0C0C0
#808000

But I can pipe no further. Judging by the error message, CUT.EXE is seeing the '|' and everything after it as part of it's command line.

v:\> type clip: | cut -d "\"" -f4 | grep .
D:\gnu\cut.EXE: |: Invalid argument
D:\gnu\cut.EXE: grep: No such file or directory
D:\gnu\cut.EXE: .: Permission denied

Any idea what's going on? ... and how to work around it?

 

[vefatica]

Quite fortunately, CUT.EXE is the only app that exhibits this odd behavior. So I must blame CUT.EXE. But I still don't understand how CUT.EXE can see the '|' (and beyond) in it's command line. I reckon TCC would have removed that stuff before starting CUT.EXE.

 

[rconn]

TCC is scanning the line after the first pipe to determine if you have additional pipes. If so, it prefixes "tcc /c" to the remainder of the line (because something like cut.exe has no idea how to handle a pipe).

In the case of your example, TCC thinks that the second pipe character is inside a double quote so it is ignored.

 

[vefatica]

I see. Redirection, '>', suffers similarly. And the work-around is (second pipe to get rid of '#').

v:\> type clip: | cut -d `\^q` -f4 | tr -d #
800080
800000
C0C0C0
808000

Or, type clip: | cut -d `"\^q"` -f4 | tr -d #

It took a bit of trial and error to come up with that one and I don't really understand why it works. I'm guessing that the \^q is still around when TCC starts the first pipe, and that newly-started TCC, not seeing an extra quote, properly starts the second pipe. ... yes/no?

It's a bit confusing, especially because that work-around fails if there's not a second pipe

Thanks!