hr for your terminal | Hacker News Reader

hr for your terminal

github.com

82 pointsC0d3r88 comments

Tired of not finding things in your terminal because there's a lot of logs and garbage? Tired of destroying the Enter key by creating a "void zone" in your terminal so that you can see the error that you're trying to debug?

Use the old <hr /> tag, but in your terminal

Open articleView on HN

If you want a solid line, you could use U+2501 (━) from the set of box drawing characters (https://en.wikipedia.org/wiki/Box-drawing_character):

    <━> 9473, U+2501 BOX DRAWINGS HEAVY HORIZONTAL

    hr(){printf '━%.0s' $(seq $COLUMNS)}

And now it works in the bourne shell!

If you want to conform to ANSI, just use two dashes (--) or ASCII, the box drawing character, the source of the unicode variant. This is important because it remains the primary font in the core of any EGA and VGA-compatible graphics card (basically all graphics cards).

ASCII doesn't have box drawing characters. ASCII is codepoints 0-127.

I'm talking about the IBM set that is most common in western locals, often called extended ASCII or just ASCII (since IBM PC became the standard)

Some terminals support ACS (with SCLD) but not unicode. It might be better to use ACS:

    $ hr() { printf '\e(0'; printf 'q%.0s' $(seq $(tput cols)); printf '\e(B'; }

Same thing, but potentially more portable.

edit: Could also use tput instead of $COLUMNS. Sometimes the $COLUMNS may not always be updated (bash's checkwinsize option).

For portability you should also use \033 (the octal code) instead of \e, which is non-standard.

Indeed, printf is shorter. I use it in a similar fashion in my own script [1], which can be made to behave like hr() (haven't tried shells other than bash):

    centered_output '=' ''

[1] https://github.com/ppurka/sh_functions/blob/master/my_bash_f...

Great idea, one random nitpick:

    curl https://raw.github.com/LuRsT/hr/master/hr > ~/bin/hr

is just evil. That's a great way to own a machine. You can even read the code today, but run the command tomorrow when someone had replaced the code with a giant exploit. Not saying there is a better way to distribute something like this that is as easy to use, but damn, this is just asking for trouble.

I know that, I did not want to be evil writing that in the instructions but that's the best way to copy that file, also this is a file to be executable, so even if you use wget you are asking for trouble, downloading a file to your $PATH and making it executable, do you have any idea on how to improve the instructions?

I honestly don't know of another way, other than encouraging the user to read the code.

Make a Homebrew version :)

Practical example: http://russianroulette.sh

How is it worse than: $ ./configure && make

I guarantee you that it'd be easier to hide something nefarious in 3000 lines of autoconf boilerplate.

It's not. And at least the download here is over HTTPS, not HTTP. But you are right, both are vulnerable unless the user is ready to be cautious.

Well if it's not, then how exactly is it "evil"? Do you audit install scripts and source code before using software?

Well, technically, I trust the Debian developers to do that for me. And I verified that they have approved of the software automatically, by checking their signatures on the Release file, which contains the hashes of the packages.

So you only install signed Debian packages then?

If I have the option to, yes. Or rather I take much less care to actually read the code when I am installing a package out of the Debian repo's. Otherwise, I at least try to review what the heck that I am installing, especially on my own machine.

Run the command, then look through the local copy to make sure it's safe. Once you have downloaded the code, there's no way that the project owner could change your copy.

Yup, that's the only way to see if what you are downloading is safe. Unfortunately, not many people will do that.

And how is this different from downloading any other source code or compiled executable from the web?

Not sure if you replied to the wrong comment by accident, but the person you replied to is agreeing with you, while making a general statement about how they wish more people checked the code they're running between the download and run steps.

I think you may have mistaken that for the "curl ...|sh" idiom?

Not really: unless you inspect ~/bin/hr before using or updating it, both boil down to the same thing.

So does any package installation where you don't read the source. Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.

> Piping curl into the shell is bad because the server can choose to serve malicious content to your curl that it didn't show in the browser.

And to head off objections, Piping curl into the shell does not leave any record on disk, unlike the "download .... ./execute" workflow in which it is trivial and natural to insert "and take a quick peek at it too".

Edit: And in the best case scenario, where the script delivered by curl is perfectly innocent, it is still a bad idea since you are left with no authoritative record of what was done. You could run curl again in the future, but that assumes that the same version is delivered, or that the file is still there at all.

Not quite true. Not all packages are created equal. For example anything from PyPI, npm, Ruby Gems, and Homebrew is suspect. On the other hand Debian/Ubuntu or Red Hat repo's are likely much more trustworthy since they have actual paid trusted maintainers who review the source code.

Not sure where you got that impression. In lots of cases, package maintainers are people who use the software and are volunteering their time to bundle it up with the necessary bits to put in a distro repo. The same is true of language-specific repos or homebrew.

Nope, "curl |bash" is worse, because (a) if there's any network problems when downloading it might split a command in half. like "rm -rf /tmp/$PID". What happens if the bytes after the first / are dropped? and (b) at lease you have the option of reviewing it when you download the script.

This doesn't contradict at all what I said. (See http://idioms.thefreedictionary.com/boil+down+to)

I just built a nodejs version of this, available on npm.

http://www.github.com/jaredsohn/hr

Install it via 'npm -g install hr'.

A benefit of this is you can also use it in your node programs (and clientside JS if you use something like browserify.)

And like any software you install that doesn't run in a sandbox, you should look at the source before running it or have some other reason for trusting it. (I briefly thought about how ironic it would be to have this program do something evil, but decided against it.)

When are these comments going to stop? Everyone lazy enough is going to keep suggesting "curl install" and everyone lazy enough is going to keep using it, and everyone that has something worth protecting and cares enough is either not going to use it or is going to audit it anyway, and comments like this aren't going to move anyone between those camps.

If you all think "curl install" is so evil then build something secure to replace it. It's got to be as easy from a "package maintainer" as well as a user's perspective, and you have to figure out some way to validate security. But until then, warning people that they should read code they execute is a waste of bandwidth.

It's never a waste of bandwidth if it prompts one person to do the critical checks and prevents them from being owned.

This has me wondering, why haven't terminal windows evolved functionally to better support history, scrollback buffers jumping or markers, selection with a mouse, auto-complete hints, etc. Instead we're limited to hacks like this or the screenshot at http://unix.stackexchange.com/questions/3650/would-it-be-pos... ... and no, I don't think "use emacs" is an acceptable answer ;-)

Oh and instead of adding blank lines with "Enter", I often just type "clear" and hit return. Bingo, tons of whitespace now added.

I use clear too, far too often, but with tmux, when you scroll up, you don't get the tons of whitespace that you get with just the terminal :(

I've often wondered if there is a terminal which supported the "jump to previous input" functionality described in the stackexchange question but I've never seen anything better than what is mentioned in the answers. I've heard Plan 9's Rio supported something like this but searching around, I can't see any mention of it.

I think terminology [1] is quite promising, although it doesn't yet do all of the above.

[1] http://www.enlightenment.org/p.php?p=about/terminology

Huh. From there I discovered http://acko.net/blog/on-termkit/

Previous thread: https://news.ycombinator.com/item?id=2559734

"What happened to TermKit?" on Reddit with a reply from the author: http://www.reddit.com/r/programming/comments/137kd9/18_month...

I'm thinking we'll need a terminal window that interfaces with bash but has overlays in HTML and other controls for scrollback, etc. Maybe a fork of an existing terminal.

The iTerm2 nightly builds have everything you asked for. See here for info about marks in history: https://code.google.com/p/iterm2/wiki/MarksAndNotes

More info about the general idea of integrating the terminal with the shell, including command history: http://www.iterm2.com/shell_integration.html

I expect FinalTerm will do something along the lines of marks as well, and has introduced some cool ideas with history.

Of course, iTerm2 has has had autocomplete for years.

If you'd like a shinier <hr> in iTerm2, you could use this script:

#!/bin/bash # usage: hr image.png printf '\033]1337;File=inline=1;width='`tput cols`';height=8px;preserveAspectRatio=0:' base64 < $1 printf '\007'

i forked this to do something immature instead because i'm 12 years old.

$ dong 8=================================D # Till the end of your terminal window $

https://github.com/tgrochowicz/hr

Hardly cause to fork a project - surely it would make more sense as an option to the original?

should rename it to hrd

I currently just mash <return> <return> <return> to create a visual break in my terminal output.

Me too, and it's exactly why I made this script :)

Some other characters you may want to substitute into the script:

――――――――――――――――――――――――――――――――――――――――――――――――――

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅┅

██████████████████████████████████████████████████

Oh yeah! Definitely! Although, to make this non-unicode compatible, it's better to have a cleaner default like '='.

But if you really want another character by default, you can do this:

    alias hr='hr █'

Much simpler: having a colored prompt works quite well to solve the mentioned problem.

PS1="\[\033[0;31m\][\u@\h:\w]$\[\033[0m\]"

Or a colored prompt with a timestamp and hostname, great with a huge scrollback.

PS1='\[\033[1;32m\](\A) <\h> [$PWD \$ \[\033[m\]'

Edit: Using tmux with a 200,000 line scrollback, you can also search scrollback based on the hour in which you ran the command. A search for "(12:" would put you right in the ball park.

I just stuck this in my PS1:

    hr() {
        printf '=%.0s' $(seq $((${COLUMNS} - 20)))
    }

    PS1="${GREY}\d ${RED}\$(hr)${GREY} \t"

It dynamically adjusts to the width of the terminal, and looks like this:

    Mon Feb 10 ======================================== 16:30:30

My complete BASH prompt: https://bitbucket.org/wyatt/dotfiles/src/25cb260a05b68dd81a5...

Great little script. I tossed it into by bash functions and added a bit of error checking and output formatting: https://github.com/jamestomasino/bash-scripts/blob/master/.f...

I like to use terminal colors so it's red, as well as allowing controlling width, but defaulting to terminal width.

  $ cat ~/bin/br
  #!/bin/sh
  if [ "$1" == "" ] ; then
          COLS=`tput cols`
  elif [ "$1" == "--help" ] ; then
          echo "$0: Prints a red line across the screen. or $0 <##> for a specific width."
          echo "$0:   br ; grep -ir foo *  -- place a marker to see where results begin / end."
          echo "$0:   br 80 ; cat file     -- use to check for overly long lines."
          exit
  else
          COLS=$1
  fi
  LINE=""
  for (( x=0 ; x<$COLS ; x++ ));  do LINE="$LINE-" ; done
  echo -e '\E[47;0m'"\033[1m$LINE\033[0m"

I'm interested why they use "seq"? [seq can take a single value too apparently, perhaps they did half width rulers with "seq 2 $(tputs cols)"?]

Why doesn't

    !/bin/bash
    j=$(tput cols); for i in {1..$j}; do echo -n "#";done

work, presumably there's some escape that needs doing?

The alternative:

    !/bin/bash
    for (( c=1 ; c<=$COLUMNS; c++ )); do echo -n "#";done

seems fine?

Also BASH has $COLUMNS builtin FWIW, though portability explains use of tput.

I like it, should be a standard command, including options to specify width as a proportion and to add whitespace lines. Code for this must be in almost every shell script.

Both of those would work in bash, but they're non-standard extensions. The seq construction would work in any POSIX shell, though the seq command itself is still non-standard I think.

Sorry, the first doesn't work - I was asking if anyone knew why. The second works in BASH, but it's bashism as you note.

hr(){printf '=%.0s' $(seq $COLUMNS)}

What language is that?

zsh

yup, using zsh, I tend to forgot that Bash needs spaces inside brackets. This is a good reminder though:

:(){ :|:& };:

Edit: don't run this, it's a forkbomb

And double check the formatting before you tattoo it on your arm.

bash shell, although some whitespace is missing:

    hr() { printf '=%.0s' $(seq $COLUMNS); }

printf is a bash builtin

Actually printf is a POSIX standard shell utility. Bash happens to implement it as a builtin, but there's also a conforming copy in GNU coreutils (and presumably busybox, but I didn't check). And the syntax above is standard Bourne shell, not specifically bash.

Actually of the constructs in that, the only non-portable one is the seq tool, which (I think) is unique to coreutils.

I don't know if its still the case, but OSX used to not ship with seq. Instead, you had to use jot.

OSX 10.9 ships a 'seq'. This particular version was written in 2005 by the NetBSD project, and its provenance is NetBSD 3.0 -> FreeBSD 9.0 -> OSX.

Fwiw, it isn't a GNUism, though GNU's version was the first widely distributed one. A 'seq' appears in some old Research UNIX editions, and also in Plan9, but not in commercial AT&T Unix or in BSD. Instead 'jot' is the traditional BSD utility. Not sure if commercial AT&T Unix (and descendants) had anything similar.

nice and simple! added to my .zshrc :)

Here is a copy-n-paste to your bash prompt:

    function hr { printf '=%.0s' $(seq $COLUMNS); }

If you like this idea and are stuck in Windows, this does the same thing:

    @set @jScript=1;/*
    @for /f "tokens=1,2" %%w in ('mode con:') do @if "%%w" == "Columns:" set cols=%%x
    @cscript /noLogo /E:jScript  "%~f0" %cols% %1 =
    @Goto :EOF
    */line='';while(line.length<WScript.Arguments(0))line+=WScript.Arguments(1);
    WScript.StdOut.Write(line.substr(0,WScript.Arguments(0)));

Save as hr.cmd and stick it somewhere in your path.

Fortunately this is what I've used Figlet (http://www.figlet.org) or Toilet (http://caca.zoy.org/wiki/toilet) for:

    $ figlet -- ----------
    
    
     _____ _____ _____ _____ _____ _____ _____ _____ _____ _____
    |_____|_____|_____|_____|_____|_____|_____|_____|_____|_____|

love useful utilities like this. Nothing rocket science but handy. I updated the README.md btw and pull request already accepted. Thx :)

Thanks! This is actually what I love doing, small utilities to help me and others which are not that fancy but get the work done and are compatible with my workflow.

Simple and useful - thanks!

I don't understand - is there something better about this than the 'clear' command?

Clear doesn't do anything to differentiate new output from old.

It makes an entire blank line, which is sufficient if you have a lot of textual output. It also gets rid of the old stuff from the screen - if you're running a window manager, you can then scroll up if you need the old stuff.

I use `clear` but in tmux, the whitespace produced by `clear` disappears, so it's the same as pressing <Enter> :(

Anyone know how to add this sort of thing before the prompt in `git add -p` ?

You can create an alias in git like this:

vim ~/.gitconfig

    ap = !hr && git add -p # Add this line to your file

The one problem is that the ability or substitute a different character doesn't test for length. I want to do: hr --==##==

That's an awesome idea, hold on...

My nodejs version does this. (npm -g install hr).

Hi! I implemented your idea, now you can do that! Thanks for your input!

Perl on Windows;

   perl -e "$_=`mode`;/ns:\s+(\d+)/;print '='x$1"

I've long wanted a shell with logical separation of each command/output pair.

I thought control + l was a fairly well known hotkey?

it inserts a terminal worth of line breaks

PS1="$(hr -) $PS1"

Beautiful.

Now I need a way to make this happen in SBT too.

Nice and useful! Thanks!

Love this, thanks!

Love it. Thanks!

Reply on news.ycombinator.com