How do we intercept file saving or output to stdout directly

[almahdi]

How do we intercept and redirect file saving or output to stdout directly in
bash, just like e.g

xkbcomp $DISPLAY

will output and generated a file, but what needed is to put it directly to
stream of stdout which will be piped once.
Tried,

$ xkbcomp $DISPLAY >(cat)
Error: Cannot open "/dev/fd/63" to write keyboard description
Exiting

$ xkbcomp $DISPLAY /dev/stdout
Error: Cannot open "/dev/stdout" to write keyboard description
Exiting

Anyone experience or have insight on this ?




--
Sent from: http://gnu-bash.2382.n7.nabble.com/

[Robert Elz]

Date: Sun, 23 Aug 2020 23:17:32 -0700 (MST)
From: almahdi <budik...@gmail.com>
Message-ID: <1598249852...@n7.nabble.com>

| How do we intercept and redirect file saving or output to stdout directly in
| bash, just like e.g
|
| xkbcomp $DISPLAY

I think you're just experiencing an oddity with xkbcomp and if
you want to report an issue, it is with the X11 project that you
should be talking, this one has nothing to do with bash.

The problem is that xkbcomp (for whatever reason) wants to
unlink the file it is going to write to before creating a new
one, and, kind of obviously, no matter what magic name you
give, you cannot unlink stdout.

You can however do (or at least, on my system, I can do)

xkbcomp -o - $DISPLAY

and that seems to work (it is often worth testing whether "-"
works for stdin/stdout when all else has failed - programs
sometimes special case that name).

kre

[Dale R. Worley]

almahdi <budik...@gmail.com> writes:
> How do we intercept and redirect file saving or output to stdout directly in
> bash, just like e.g
>
> xkbcomp $DISPLAY
>

> will output and generated a file, but what needed is to put it directly to
> stream of stdout which will be piped once.

...

> $ xkbcomp $DISPLAY /dev/stdout
> Error: Cannot open "/dev/stdout" to write keyboard description
> Exiting

Normally, that should work.

But I get the same error message as you do. I did a trace on xkbcom and
I see at the end:

open("/dev/stdout", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 EEXIST (File exists)
write(2, "Error: ", 18Error: ) = 18
write(2, "Cannot open \"/dev/stdout\" to wri"..., 56Cannot open "/dev/stdout" to write keyboard description
) = 56

The open() is done with the O_EXCL flag. Reading the manual page
open(2), I see that O_EXCL requires that the open() call creates the
file.

It's not clear why xkbcomp has this behavior, but it seems likely that
this is done for a specific reason. So you will have to ask whoever
maintains it.

I don't see any option that overrides this behavior.

However, as Robert said, many programs handle an argument "-" specially
as a reference to stdin or stdout. And it turns out that (my version
of) xkbcomp does so:

$ xkbcomp $DISPLAY -
xkb_keymap {
xkb_keycodes "evdev+aliases(qwerty)" {
minimum = 8;
maximum = 255;
<ESC> = 9;
<AE01> = 10;
...

Dale

[Greg Wooledge]

On Wed, Aug 26, 2020 at 12:01:26AM -0400, Dale R. Worley wrote:
> open("/dev/stdout", O_WRONLY|O_CREAT|O_EXCL, 0666) = -1 EEXIST (File exists)
> write(2, "Error: ", 18Error: ) = 18
> write(2, "Cannot open \"/dev/stdout\" to wri"..., 56Cannot open "/dev/stdout" to write keyboard description
> ) = 56
>
> The open() is done with the O_EXCL flag. Reading the manual page
> open(2), I see that O_EXCL requires that the open() call creates the
> file.
>
> It's not clear why xkbcomp has this behavior, but it seems likely that
> this is done for a specific reason. So you will have to ask whoever
> maintains it.

The obvious guess is that it's to "prevent you from accidentally
overwriting a file".

[Robert Elz]

Date: Wed, 26 Aug 2020 08:13:52 -0400
From: Greg Wooledge <woo...@eeg.ccf.org>
Message-ID: <2020082612...@eeg.ccf.org>

| The obvious guess is that it's to "prevent you from accidentally
| overwriting a file".

That would be what one would normally assume, but Dale didn't
show what comes just before the open (this sys call trace is
from a different OS, so the format is different)

28469 28469 xkbcomp CALL unlink(0x7f7fffffec7b)
28469 28469 xkbcomp NAMI "/dev/stdout"
28469 28469 xkbcomp RET unlink -1 errno 13 Permission denied
28469 28469 xkbcomp CALL open(0x7f7fffffec7b,0xa01,0x1b6)
28469 28469 xkbcomp NAMI "/dev/stdout"
28469 28469 xkbcomp RET open -1 errno 17 File exists

If it was attempting to "prevent you from accidentally overwriting a file"
it is unlikely it would be unlinking it (or attempting to) first.

(0xa01 == O_EXCL|O_CREAT|O_WRONLY 0x1b6 == 0666).

If one were to execute xkbcomp as root (people, please don't)
then all of this would probably succeed, and replace /dev/stdout
with a regular file containing the xkbcomp output.

kre

[Greg Wooledge]

On Thu, Aug 27, 2020 at 05:26:46AM +0700, Robert Elz wrote:
> 28469 28469 xkbcomp CALL unlink(0x7f7fffffec7b)
> 28469 28469 xkbcomp NAMI "/dev/stdout"
> 28469 28469 xkbcomp RET unlink -1 errno 13 Permission denied
> 28469 28469 xkbcomp CALL open(0x7f7fffffec7b,0xa01,0x1b6)
> 28469 28469 xkbcomp NAMI "/dev/stdout"
> 28469 28469 xkbcomp RET open -1 errno 17 File exists

Ahh. Then I revise my guess to "an attempt to prevent someone sneaking
in a symlink between the unlink and the open", i.e. classic race condition
security for publically writable directories like /tmp.