output options

[luisdavim]

the original grc has the following options:

-e --stderr    redirect stderr. If this option is selected,
               do not automatically redirect stdout
-s --stdout    redirect stdout, even if -e is selected
-c name --config=name    use name as configuration file for grcat
--colour=word  word is one of: on, off, auto
--pty          run command in pseudoterminal (experimental)

How does rgrc handle stdout, stdr and pty (for example ssh and kubectl exec)?

Oh and BTW grc uses colour whilst rgrc uses color to make it a real drop-in replacement it would be nice if rgrc would also support --colour :)

[strafer]

@luisdavim I somehow missed the option -c/--config from grc itself when I added aliases to my .zshrc in the past, I added this to my issue, thanks for the hint.

[lazywalker]

the original grc has the following options:

-e --stderr    redirect stderr. If this option is selected,
               do not automatically redirect stdout
-s --stdout    redirect stdout, even if -e is selected
-c name --config=name    use name as configuration file for grcat
--colour=word  word is one of: on, off, auto
--pty          run command in pseudoterminal (experimental)

How does rgrc handle stdout, stdr and pty (for example ssh and kubectl exec)?

rgrc does not create a local PTY at the moment. If rgrc pipes the child’s stdout (the normal colorizing path), the child process will see a pipe (non-TTY) on its stdout; many programs (and remote commands) detect this and will disable interactive features and colors.

For remote/interactive sessions you typically need a local PTY. Because rgrc never allocates one, wrapping interactive commands with rgrc can break interactivity. Examples:

• ssh -t host command: -t forces a remote PTY, but the local ssh client’s stdout will still be a stream; if rgrc pipes that stdout, the remote program may not get the local-tty behavior you expect.
• kubectl exec -it ...: the -t/-i flags affect remote pty/stdin handling, but rgrc wrapping and piping stdout will still present a non-tty to the child on the local side, which can disable interactive behavior.

Key differences from rgrc:

1. Original grc has selective stderr/stdout redirection: you choose which streams to colorize via -e and -s flags
2. rgrc currently:
   • Only pipes and colorizes stdout (never stderr)
   • No -e / -s / --pty flags available
   • Uses simple TTY detection (isatty) instead of pty allocation

For interactive commands (ssh, kubectl exec):

Original grc with --pty: Would allocate a local PTY, run the command in it, and forward the colored output—allowing interactive features to work.

rgrc: Since there's no --pty support and stdout is piped when colorizing, interactive commands lose their TTY and can't provide interactive prompts/colors.

The workaround in rgrc: Don't wrap interactive commands with rgrc—run them directly, or use --color=off when you need interactivity.

Oh and BTW grc uses colour whilst rgrc uses color to make it a real drop-in replacement it would be nice if rgrc would also support --colour :)

agree, it would be nice to have both color and colour supported :)