I use a patched rxvt-unicode which support sixel

[shellkr]

I use this patch rxvt-unicode-sixel.patch which adds sixel support for rxvt-unicode.

But when I try to use lsix it will silently crash. I do not get a warning or anything. With unpatched rxvt-unicode it will give me a warning that the terminal emulator is not supported but now when it is patched it just silently die.

[hackerb9]

Try cd'ing to that directory and running lsix within it.

[shellkr]

Nope.. same thing. Silently crash.

[hackerb9]

Hmmm. You tried 'lsix image.png'? Or you are just running 'lsix'?

I bet it's not crashing. It's probably sending an escape sequence that rxvt is ignoring. Try redirecting stdout to a file to see what is actually getting sent to the terminal.

lsix > output

You have TERM set to rxvt? If so, it should be sending only slightly more than 'convert', which you've already shown works. Just a few inquiries to find your terminal size and background color.

This is unlikely, but you are trying png files, right? I've seen some installations of ImageMagick that require helper programs to deal with unusual formats, including webp.

[shellkr]

Yes TERM is set to rxvt-256color and yes, I try png files. I tried both lsix > output and lsix image.png > output but it is still silent. I did a strace that can be found here.

[hackerb9]

Yes, it should be silent because the output was written to the file. Was the output file empty or did it contain escape sequences which rxvt discarded?

An 'strace' isn't terribly useful for a shell script. If you'd like to trace it, you'd need to run bash with the -x option (as in #!/usr/bin/bash -x). However, since I reset argv in lines 172 and 182, you'd need to use set -x again afterward to restart tracing.

[shellkr]

Sorry, was not clear... yes, the file was empty.

Yeah, I know... it is simple to do so thought it might be better than nothing.

I am currently trying to debug by putting in checks and you are right. It does not crash. I noticed though that something happens the the env. Because before I run lsix the manual convert works but not after.

[shellkr]

Some success.. It seems like the escape sequence in the end doesn't work so well in Zsh. So I tried a quick and dirty bash -c 'read -s -t 60 -d "c" -p $'\e[c' >&2' which worked somewhat.

https://superuser.com/questions/555874/zsh-read-command-fails-within-bash-function-read1-p-no-coprocess

[hackerb9]

Huh? How is zsh mixed up in this? Even if that's your shell, when you run lsix, it will be interpreted by bash. (Unless I've done something horribly wrong. :-)

If convert works before, but not after lsix, one possible cause is a bug in rxvt. Try narrowing down which escape sequence is the culprit. You can then let the rxvt folks know that it is messing up the sixel parsing.

[bkdwt]

Lsix still not working for me on Fedora, even using xterm -ti vt340 command.

[hackerb9]

That's good to know. Would you please start a new bug so we can track the problem with Fedora? This bug you posted on is for rxvt.

[hackerb9]

Lsix still not working for me on Fedora, even using xterm -ti vt340 command.

@bkdwt I've moved your question to bug #29. Let's continue the conversation there.

[hackerb9]

Some success.. It seems like the escape sequence in the end doesn't work so well in Zsh. So I tried a quick and dirty bash -c 'read -s -t 60 -d "c" -p $'\e[c' >&2' which worked somewhat.

@shellkr I haven't heard from you in a bit, so I'm going to close this issue. Feel free to re-open it if you have more info about rxvt's sixel implementation.