Save output to ansi text file

[greenseeker]

Is there a way to save the output as an ansi text file? If I try to redirect output, it barfs during terminal size detection. If I also specify the output size with -d, it complains the terminal is too small.

Update: I was able to capture the output using script but it would certainly be nice to have a proper save-as-ansi option.

[TheZoraiz]

@greenseeker I'm taking a guess here, but I believe the error occurs because you're redirecting stdout to a file. The tool detects terminal size from stdout every time, which is usually the terminal, so I can see how that's an issue. Custom dimensions also won't work since they check whether the width exceeds the terminal (stdout again) as well.

I wanted to keep the flags simple for most users so I'm not sure about adding character encoding functionality, because then covering only ANSI characters set would seem inappropriate. For the time being, I believe you can change the saved text file encoding with CLI tools like iconv or recode.

Will have to think about this. Thanks for pointing out the issue though, I'm a bit busy these days but I'll try to make a fix soon.

[greenseeker]

I suspected the same regarding the crash/failure when redirecting output.

You're already encoding it in ansi to write to the screen; I was just looking for a nice way to save that to a file as well. If you were to do so, optimizing the escape codes would be nice also. At the moment, the color is being reset to defaults and then set to the new color in between every character, even if that character is the same color as the previous one.

[TheZoraiz]

@greenseeker Released the patched version 1.3.4. Wrote some conditions where terminal size will be calculated through stdin if stdout is redirected somewhere. This could be potentially breaking for library usage without CLI but I'll look into it later. Pipes with commands like grep should now work too. This patch isn't available for windows yet since I'm still figuring that out.

Optimizing escape codes seems like a good idea, but I don't think it'll be very effective overall. You see, I'm encoding each character with RGB values, which are not usually the same for two adjacent ascii characters. At best, for usual images, you'd find 2 or 3 characters with the same color codes adjacent to each other. I could optimize it a little bit but it seems overkill for not enough benefit. Let me know if I'm missing something here.

I believe this issue is resolved now so I'm closing it :)