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 informationI 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/nullto 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,560starts 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,560which starts display in the shell background then immediately continues with the remaining commands.
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
wmctrlis 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
:0when 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
$XAUTHORITYis 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
~/.xprofileor~/.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