31–40 of 111 posts
Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html
Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html
I wonder if any other terminal uses the same escape sequences. If not, why not?
You can also specify filenames and, of course, use shell wild cards However, some may be slow to render (like PDF), so lsix doesn't show them unless you ask specifically. Regardless of the justification, I don't think creating such extra exception/edge-case behaviours are ever a good idea in a commandline tool like this. The equivalent in regular ls would be something like not showing more than X files "unless you as…
If it didn't preview GIFs without a flag, or PNGs, then your point would absolutely stand.
Aside: Although iTerm2 (on macOS) doesn't appear to work with this, iTerm2 actually supports full-color inline images, and has an "imgls" script which does something similar. (There's also "imgcat".) https://www.iterm2.com/documentation-images.html
>iTerm2 extends the xterm protocol with a set of proprietary escape sequences. I wonder if any other terminal uses the same escape sequences. If not, why not?
(Aside: I dislike the vagueness of the term "proprietary." I rarely hear anyone call the non-ANSI VT-100 or xterm sequences "proprietary," even though they got started in exactly the same way as iTerm2's.)
Earlier quoted context omitted.
It's also facinating that programs that generate text output do so in a format that's well over 40 years old. What if our CLI programs could output HTML or JSON depending on whether they are piped or printed. Both standards are not good for this, but is VT100 really that great?
Most terminals use unicode, not ascii, right? Unicode is much younger than 40.
Wouldn’t this be more like “cat” than “ls”? List is for listing files, cat is for outputting the files, and this appears to output the image...
Earlier quoted context omitted.
As far as I know it's just xterm on desktop. It's fascinating that we have this standard that allows us to build programming environments like notebooks -- without resorting to layering hacks on hacks to make it work on web -- practically crossplatform yet we don't make use of it. At repl.it we've been toying around with adding sixel support for xterm.js and we have a prototype up and people in our community are alre…
It's also facinating that programs that generate text output do so in a format that's well over 40 years old. What if our CLI programs could output HTML or JSON depending on whether they are piped or printed. Both standards are not good for this, but is VT100 really that great?
Earlier quoted context omitted.
>iTerm2 extends the xterm protocol with a set of proprietary escape sequences. I wonder if any other terminal uses the same escape sequences. If not, why not?
hterm, the terminal emulator portion of the Chrome (OS) Secure Shell app, supports them. (Aside: I dislike the vagueness of the term "proprietary." I rarely hear anyone call the non-ANSI VT-100 or xterm sequences "proprietary," even though they got started in exactly the same way as iTerm2's.)
iTerm2 calls their escape codes proprietary[0]. As far as I can tell, they are not trying to create a standard. VT320, on the other hand, is an ANSI standard[1].
Earlier quoted context omitted.
ls does not show files starting with .
Yeah, but those files are known as "hidden files". In other words, it is the creators of those files who purposefully prepend them with a . to hide them from ls and other tools. One can argue whether this "starting with a . means hidden" is a hack or not, but I think it's manifestly different than not showing particular file types based on size or something like that. I agree just not showing pdf files by default bec…
The story from Rob Pike is that this came about from a combination of (1) not wanting to show "." and "..", and (2) some sloppy programming in the implementation of that feature.