Reason to prefer head or tail of cargo check output?

#1

It’s not uncommon to have cargo check outputting a little more than what fits the screen.

In most languages looking at the start would be a good idea because most tail errors are really consequences of the ones at head.

In rust we could for example use something like

cargo --color always check 2>&1 | head -n 80

but I’m unsure for rust, as the last outputted errors don’t seem irrelevant.

Is there a reason to prefer one end ? What’s your practice ?

  • read head first
  • read tail first
  • unsure

0 voters

#2

In most languages looking at the start would be a good idea because most tail errors are really consequences of the ones at head.

This is true just as much in Rust. When there are lots of errors, I have found it to be much more frequently productive to start processing from the first error rather than from the end.

#3

I found one reason to use head first (with an alias to a head command): the head appears very fast while I must frequently wait several seconds for the end.

So I just made myself this:

alias cck="cargo watch -s 'cargo check --color always 2>&1 | head -n 50'"
#4

in my case I use the following command:

$ cargo check --color=always | less -R

It has the advantage of showing the starting output of cargo check, while still allowing you to scroll down for errors

2 Likes
#5

iTerm2 on macOS has a great feature to jump to “previous mark/annotation” (keyboard shortcut: command-shift-up), and it sets a mark at each command prompt. It’s super useful to jump to the start of the output at the previous command! More docs here :slight_smile:

1 Like