Hide

What's this?

commandlinefu.com is the place to record those command-line gems that you return to again and again.

Delete that bloated snippets file you've been using and share your personal repository with the world. That way others can gain from your CLI wisdom and you from theirs too. All commands can be commented on, discussed and voted up or down.


If you have a new feature suggestion or find a bug, please get in touch via http://commandlinefu.uservoice.com/

Get involved!

You can sign-in using OpenID credentials, or register a traditional username and password.

First-time OpenID users will be automatically assigned a username which can be changed after signing in.

Hide

Stay in the loop…

Follow the Tweets.

Every new command is wrapped in a tweet and posted to Twitter. Following the stream is a great way of staying abreast of the latest commands. For the more discerning, there are Twitter accounts for commands that get a minimum of 3 and 10 votes - that way only the great commands get tweeted.

» http://twitter.com/commandlinefu
» http://twitter.com/commandlinefu3
» http://twitter.com/commandlinefu10

Subscribe to the feeds.

Use your favourite RSS aggregator to stay in touch with the latest commands. There are feeds mirroring the 3 Twitter streams as well as for virtually every other subset (users, tags, functions,…):

Subscribe to the feed for:

Hide

News

2011-03-12 - Confoo 2011 presentation
Slides are available from the commandlinefu presentation at Confoo 2011: http://presentations.codeinthehole.com/confoo2011/
2011-01-04 - Moderation now required for new commands
To try and put and end to the spamming, new commands require moderation before they will appear on the site.
2010-12-27 - Apologies for not banning the trolls sooner
Have been away from the interwebs over Christmas. Will be more vigilant henceforth.
2010-09-24 - OAuth and pagination problems fixed
Apologies for the delay in getting Twitter's OAuth supported. Annoying pagination gremlin also fixed.
Hide

Tags

Hide

Functions

PRINT LINE the width of screen or specified using any char including Colors, Escapes and metachars

Terminal - PRINT LINE the width of screen or specified using any char including Colors, Escapes and metachars
L(){ l=`builtin printf %${2:-$COLUMNS}s` && echo -e "${l// /${1:-=}}"; }
2010-06-14 04:35:30
User: AskApache
Functions: echo printf
2
PRINT LINE the width of screen or specified using any char including Colors, Escapes and metachars

One of the first functions programmers learn is how to print a line. This is my 100% bash builtin function to do it, which makes it as optimal as a function can be. The COLUMNS environment variable is also set by bash (including bash resetting its value when you resize your term) so its very efficient. I like pretty-output in my shells and have experimented with several ways to output a line the width of the screen using a minimal amount of code. This is like version 9,000 lol.

This function is what I use, though when using colors or other terminal features I create separate functions that call this one, since this is the lowest level type of function. It might be better named printl(), but since I use it so much it's more optimal to have the name contain less chars (both for my programming and for the internal workings).

If you do use terminal escapes this will reset to default.

tput sgr0

For implementation ideas, check my

http://www.askapache.com/linux-unix/bash_profile-functions-advanced-shell.html

Alternatives

There are 2 alternatives - vote for the best!

Terminal - Alternatives
printf "%`tput cols`s"|tr ' ' '#'
2010-04-05 17:12:35
User: kamathln
Functions: printf tr
Tags: tr tput printf
17

shorter than alternative

seq -s'#' 0 $(tput cols) | tr -d '[:digit:]'
2010-04-01 09:06:44
User: jgc
Functions: seq tput tr
Tags: seq tr tput
6

Print a row of characters across the terminal. Uses tput to establish the current terminal width, and generates a line of characters just long enough to cross it. In the example '#' is used.

It's possible to use a repeating sequence by dividing the columns by the number of characters in the sequence like this:

seq -s'~-' 0 $(( $(tput cols) /2 )) | tr -d '[:digit:]'

or

seq -s'-~?' 0 $(( $(tput cols) /3 )) | tr -d '[:digit:]'

You will lose chararacters at the end if the length isn't cleanly divisible.

printf -v row "%${COLUMNS}s"; echo ${row// /#}
2010-04-13 21:56:46
User: dennisw
Functions: echo printf
Tags: tr tput printf
4

Pure Bash

This will print a row of characters the width of the screen without using any external executables. In some cases, COLUMNS may not be set. Here is an alternative that uses tput to generate a default if that's the case. And it still avoids using tr.

printf -v row "%${COLUMNS:-$(tput cols)}s"; echo ${row// /#}

The only disadvantage to either one is that they create a variable.

println() {echo -n -e "\e[038;05;${2:-255}m";printf "%$(tput cols)s"|sed "s/ /${1:-=}/g"}
2011-01-09 18:08:18
User: joedhon
Functions: printf sed
Tags: sed tput printf
0

function for .bash_aliases that prints a line of the character of your choice in the color of your choice across the terminal.

Default character is "=", default color is white.

jot -b '#' -s '' $COLUMNS
2010-04-13 22:03:39
User: dennisw
Tags: tr tput printf
-1

For BSD-based systems, including OS X, that don't have seq.

This version provides a default using tput in case $COLUMNS is not set:

jot -b '#' -s '' ${COLUMNS:-$(tput cols)}

Know a better way?

If you can do better, submit your command here.

What others think

I don't unrdestand.

Why I can't use a simple for loop like this:

L() { for i in $(seq $COLUMNS); do echo -n "="; done; echo; }

instead your function?

Comment by unixmonkey10344 201 weeks and 2 days ago

It's really a small issue, I've just really wanted to have a function that could print a full-screen's width of characters in 1 line of code. Not 1 line of code for my eyes or to make my scripts pretty. But 1 line of code that the machine has to work. You can do it with a full printf, but using echo like this is what lets it safely handle input like terminal escapes and COMP_CHARS like *, $, etc.

It's all about the optimization. It's cheaper to append data to a variable and do 1 final echo then it is to do an echo for each char.; And it's always cheaper to use builtin function (its the shell's internal funcs!) that use the same libs than to map another process into mem.

Let's put it to the test shall we. I just turned on tracing so you can see why I'm so proud of this function.

Here's what happens with your function (I had to cut it after 5 characters to get it to fit... *not 5 lines, 5 '=' chars.

L() { for i in $(seq 1 5); do echo -n "="; done; echo; }; set -xv; L

L

L

+ L

seq 1 5

++ seq 1 5

+ for i in '$(seq 1 5)'

+ echo -n =

=+ for i in '$(seq 1 5)'

+ echo -n =

=+ for i in '$(seq 1 5)'

+ echo -n =

=+ for i in '$(seq 1 5)'

+ echo -n =

=+ for i in '$(seq 1 5)'

+ echo -n =

=+ echo

And Here's how the other one handles 263 characters (I had to cut the results this time to get it to fit, as opposed tohaving to cut the inefficient loop.)..

L(){ l=`builtin printf %${2:-$COLUMNS}s` && echo -e "${l// /${1:-=}}"; }; set -xv; L

L

L

+ L

builtin printf %${2:-$COLUMNS}s

++ builtin printf %236s

+ l=' '

+ echo -e ================================================================================================================================

Using the builtin version of printf is faster than seq, It's very simple compared to the printf's and sprintfs you are probably thinking of. While your command would also be extremelyfast, if you actually measured these 2 functions head to head it would be very obvious which one is optimal. The loop technique you have is awesome, I used to use that all the time before I started using more builtin shell techniques.

L() { for i in {1..$COLUMNS}; do echo $i; done;}

And it depends on the output buffer settings of your device, but it would be cheaper to write data to an output device 1 time rather than 80 times. Plus you have to figure that echo isn't magic, passing a function an argument requires that it be parsed, so that's $COLUMNS *1 additional internal loops for echo also. And seq requires even more processing (albeit nanoscopic). So it would be better to:

L() { for i in `eval echo {1..$COLUMNS}`; do echo $i; done do echo $i; done;} L() { local l; for i in $(seq $COLUMNS); do echo -n "="; done; echo; }

The only work that is done by this 2 command function is the printf saves a whole line of chars to a variable, then echo simply writes the value of the variable to the output, the screen, in a single write. The expansion that happens in both is as close to free as you can see in the shell. This is very optimized, and I am a huge geek when it comes to the shell.

Comment by AskApache 201 weeks ago

If you want to understand what I mean, use the strace program to trace my function, and see if you can beat it's speed. It's like a 10000x cheaper then the seq loops, which I love and use all the time myself as well.. so not dissing the seq or anything!

Comment by AskApache 201 weeks ago

Your point of view

You must be signed in to comment.

Related sites and podcasts