Solved Occasionally ugly results from script(1)

That's basically escape sequences. Not a fish thing, more a "must put colors on everything" thing.
Things like colorization of prompts, etc.
Drives me up a wall that a lot of things default to "must colorize ls output or grep output or diff output".
Not sure of exactly "what" but the output of "env" could lead you to something. I unset everything related to "colors".
 
You need to look at the output of "env | grep -i color" for a start and also any command aliases.
A lot of defaults for things like ls, grep, diff, git will create aliases explicitly adding options for colorizing the output.
script often creates files in "DOS" format so end of line has cr-lf but a simple dos2unix clears that up.
The output from the OP a lot looks like the prompt, so in the env, check for the PROMPT variable. If it has embedded escape sequences, get rid of them.
 
I hunt these suckers down and squash them. This is from my .kshrc:
Code:
case $Uname in
    Linux*) EXINIT="$EXINIT t_ti= t_te="
        alias -x ls="ls --color=never"
        alias -x grep="grep --color=never"
A quick read of the fish documentation suggests that you can remove colour from the prompt by creating a prompt function in ~/.config/fish/functions/fish_prompt.fish:
Code:
function fish_prompt
    echo -n (prompt_pwd)
    echo -n ' > '
end
 
Is this type of mess maybe more likely to occur with fish(1)?
Yes. There are functions for overriding basic commands, and fish tries to help you complete commands faster by automatically suggesting completions in the form of different-colored text, which will result in many control sequences.

However, even the simplest interactive session (pressing Ctrl-D to send EOF to the shell, making it exit) will contain control sequences. You can strip everything down as much as possible, but I still got the following typescript after pressing Ctrl-D:
Code:
Script started on Wed Sep  1 22:23:57 2021    
Command: fish -l    
^[[38;5;0m^[[m^M^[[38;5;0m^[[m^[[38;5;0m^[[m    
Command exit status: 0    
Script done on Wed Sep  1 22:24:48 2021
Those control sequences are output by a function in the fish binary itself, not by any fish shell function. While you can filter those out, fish's completion suggestions also generate additional text and control sequences, so I personally would consider fish to be incompatible with script(1).
 
Thanks, everyone.

Solved – I'll continue to prefer tcsh (and csh for the root user).

(I rarely touch fish, in this case it was preset.)
 
Actually, if you look at the control sequences, they are all super easy to decode. You might be able to remove them, or learn to ignore them. They are all of the form "[m", "[<x>m" or "<x>;<y>...m", where x and y are integers. Those are all really boring escape sequences, which change how text is rendered. In your case, the escape character at the beginning of the sequence is invisible in the script (it might be there and not getting printed to the screen), and then the escape sequence starts with "[" and ends with "m", with zero or more flags in there. Those flags all have really simple meaning: nothing at all means to back to normal rendering, 1 means boldface, 4 means underline, 30...37 are foreground colors (the ones I remember are 31=red and 32=green), 40...47 are background colors, and the others I don't know by heart.

If you configure your shell or your programs to display colors (or bold or underline or any such attributes), these escape sequences will show up in the output if you use script. That's a fundamental limitation of the approach script uses: It faithfully records everything sent to the terminal. You are blaming fish, which clearly does a lot of crazy stuff with colors. But it's by far not the only offender. Even I am part of the program: If you run my little home program "eqstat" (which gives you the status of the pump/well/water equipment), it will color-code output as green (OK, perhaps idle), blue (running), and yellow and red (warning and error), and it will boldface important information (such as the water level in the tank). This is the nature of today's terminal IO, and the old-fashioned script program is just not not prepared for this.

Your approach of avoiding fish will obviously help. But there is another possible approach: Post-process the output of script to remove just these escape sequences. There is a small program called "ansifilter" which removes rendering escape sequences, and with a little bit of programming work, you can write such a program yourself (just look for all sequences of the type "Esc [ ... m" where ... consists only of digits and semicolons, and remove them).
 
Thanks – textproc/ansifilter | ansifilter(1)

Weirdness at/around each command becomes clearer following a basic run (below), like, I typed sudo pkg upgrade (not sudo pkg upgrade /home/cultbsd), and so on.

Code:
% less /tmp/0yet7.fishy
"/tmp/0yet7.fishy" may be a binary file.  See it anyway?
%
% ansifilter -i /tmp/0yet7.fishy -o /tmp/0yet7.txt
% file /tmp/0yet7.txt
/tmp/0yet7.txt: ASCII text, with very long lines
% slowcat --bps 2400 /tmp/0yet7.txt
Script started on Wed Sep  1 09:53:29 2021
Welcome to fish, the friendly interactive shell
Type help for instructions on how to use fish
0;fish /home/cultbsd
ekhon3.8.core p/.*~>
0;sudo pkg upgrade /home/cultbsd
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01   
Fetching packagesite.pkg: 100%    6 MiB   3.3MB/s    00:02   
Processing entries:  75%
pkg: sqlite error while executing INSERT OR REPLACE INTO packages (origin, name, version, comment, desc, arch, maintainer, www, prefix, pkgsize, flatsize, licenselogic, cksum, path, manifestdigest, olddigest, vital)VALUES (?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, ?14, ?15, ?16, ?17) in file update.c:166: database or disk is full
Processing entries: 100%
pkg: sqlite error while executing ROLLBACK TO SAVEPOINT REPO in file pkgdb.c:1305: no such savepoint: REPO
pkg: sqlite error while executing RELEASE SAVEPOINT REPO in file pkgdb.c:1305: no such savepoint: REPO
Unable to update repository FreeBSD
Error updating repositories!
0;fish /home/cultbsd                                                                                                                                                                                   
vkg Xorgcultbsdpc ~ [3]>
0;pkg -vv /home/cultbsd
…
 
In this case using less -R ... to read the file is also useful.

Code:
       -R or --RAW-CONTROL-CHARS
              Like -r, but only ANSI "color" escape sequences and OSC 8
              hyperlink sequences are output in "raw" form.  Unlike -r, the
              screen appearance is maintained correctly, provided that there
              are no escape sequences in the file other than these types of
              escape sequences.  Color escape sequences are only supported
              when the color is changed within one line, not across lines.  In
              other words, the beginning of each line is assumed to be normal
              (non-colored), regardless of any escape sequences in previous
              lines.  For the purpose of keeping track of screen appearance,
              these escape sequences are assumed to not move the cursor.
 
Back
Top