By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Trouble piping

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

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?
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.
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.
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 #

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


Similar threads