How to send standard input to background job?

After several trial & error, I installed another image viewer on my remote machine (feh), setting in up— and tried the command once again.

feh WARNING: /tmp/feh_stdin_ZwCjv7 - No Imlib2 loader for that file format
feh: No loadable images specified.
See 'man feh' for detailed usage information

I think this is the problem that caused ImageMagick's display to burst out error.

display: no decode delegate for this image format `' @ error/constitute.c/ReadImage/501.

According to , the command failed because I started display as a background job (&).

If the process is started with & then the shell will actually redirect its stdin from /dev/null to avoid any read attempts.

If I removed the trailing &, the command will ran without any problem, take an example of:

Working

ssh beer@laika "DISPLAY=:0 feh -" < <(cat 1.jpeg)

(Also) working

ssh beer@laika "DISPLAY=:0 display -" < <(cat 1.jpeg)

How to send stdin to background & job ?

2 Answers

The command

display - && sleep 5 && wmctrl -r ImageMagick -e 0,254,600,800,560

starts the display command, waits for it to exit, and then runs sleep 5 && wmctrl -r ImageMagick -e 0,254,600,800,560 if the exit status indicates success.

You probably want

display - & sleep 5 && wmctrl -r ImageMagick -e 0,254,600,800,560

which starts display in the shell background then immediately continues with the remaining commands.

2

It appears to be authority issue over ssh:

DISPLAY and AUTHORITY

An X program needs two pieces of information in order to connect to an X display. (Note that wmctrl is an X program, even if it accesses other processes' windows rather than creating its own.)

  • It needs the address of the display, which is typically :0 when you're logged in locally or :10, :11, etc. when you're logged in remotely (but the number can change depending on how many X connections are active). The address of the display is normally indicated in the DISPLAY environment variable.

  • It needs the password for the display. X display passwords are called magic cookies. Magic cookies are not specified directly: they are always stored in X authority files, which are a collection of records of the form “display :42 has cookie 123456”. The X authority file is normally indicated in the XAUTHORITY environment variable. If $XAUTHORITY is not set, programs use ~/.Xauthority.

Luckily you can solve this by setting up some cookies:

To copy cookies when you log into your desktop X session, add the following lines to ~/.xprofile or ~/.profile (or some other script that is read when you log in):

case :$DISPLAY:$XAUTHORITY in :*:?*) XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

This is a small summary of the answer. Please visit the link above for all details.

1

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

You Might Also Like