one-liner vs script

Question

I've noticed a lot of questions and answers and comments expressing disdain for (and sometimes even fear of) writing scripts instead of one-liners. So, I'd like to know:

• When and why should I write a stand-alone script rather than a "one-liner"? Or vice-versa?

• What are the use-cases and pros & cons of both?

• Are some languages (e.g. awk or perl) better suited to one-liners than others (e.g. python)? If so, why?

• Is it just a matter of personal preference or are there good (i.e. objective) reasons to write one or the other in particular circumstances? What are those reasons?

Definitions

• one-liner: any sequence of commands typed or pasted directly into a shell command-line. Often involving pipelines and/or use of languages such as sed, awk, perl, and/or tools like grep or cut or sort.

  It is the direct execution on the command-line that is the defining characteristic - the length and formatting is irrelevant. A "one-liner" may be all on one line, or it may have multiple lines (e.g. sh for loop, or embedded awk or sed code, with line-feeds and indentation to improve readability).

• script: any sequence of commands in any interpreted language(s) which are saved into a file, and then executed. A script may be written entirely in one language, or it may be a shell-script wrapper around multiple "one-liners" using other languages.

---

I have my own answer (which I'll post later), but I want this to become a canonical Q&A on the subject, not just my personal opinion.

Answer 1

Another response based on practical experience.

I would use a one-liner if it was "throw away" code that I could write straight at the prompt. For example, I might use this:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

I would use a script - a program saved in a file - if I decided that the code was worth saving. At this point I would add a description at the top of the file, probably add some error checking, and maybe even check it into a code repository for versioning. For example, if I decided that checking the uptime of a set of servers was a useful function that I would use again and again, the one-liner above might be expanded to this:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Generalising, one could say

• One-liner

  • Simple code (i.e. just "a few" statements), written for a specific one-off purpose
  • Code that can be written quickly and easily whenever it is needed
  • Disposable code

• Script

  • Code that will (probably) be used more than once or twice
  • Complex code requiring more than "a few" statements
  • Code that will need to be maintained by others
  • Code to be understood by others
  • Code to be run unattended (for example, from cron)

I see a fair number of the questions here on unix.SE ask for a one-liner to perform a particular task. Using my examples above, I think that the second is far more understandable than the first, and therefore readers can learn more from it. One solution can be easily derived from the other so in the interests of readability (for future readers) we should probably avoid providing code squeezed into in one line for anything other than the most trivial of solutions.

Answer 2

Write a script when:

• more code is required
• you value readability
• it is necessary/useful to add comments, to show what the code does
• you need to pass parameters
• you want the script to run in its own environment (variables, etc.)
• you are probably going to reuse/adapt the code for some more complex purpose

Write a one-liner when:

• only a small amount of code is necessary
• you want to access variables defined in the current shell
• you need a quick & dirty solution

Answer 3

When a required series of commands is fairly short and/or produces a result that could be usable as a part of a larger pipeline or a command alias, it might be a good one-liner.

Basically, I think one-liners are usually things that a seasoned system administrator familiar with both the problem and the commands used might write on the spot, without too much thinking.

When an one-liner becomes excessively long or involves more than very simple conditionals or loops, it is usually better to write them as a multi-line script or shell function, for readability. Also, if it's something you write to be used again and again, or something that will be used (and possibly troubleshot) by other people, you should be willing to spend the time to write the solution into a clear(er), commented, script form.

In Python, indentation is part of the syntax, so you literally cannot use the features of the language to their full extent if you write a one-liner.

Perl and awk one-liners are often about using the raw power of regular expressions. But some call regular expressions a Write-Only Language, not entirely without reason. Writing a multi-line script allows you to write in comments to describe what a particular regular expression is supposed to be doing, which will be very helpful when you look at the script again, after doing other things for six months in between.

This is inherently a very opinion-based question, as it involves gauging what amount of complexity is acceptable and tradeoffs between readability and compactness; all of these are very much matters of personal judgement. Even the choice of a language can depend on personal matters: if a particular language would theoretically be optimal for a particular problem, but you're unfamiliar with it, and already know how to solve the problem with some other language, you may choose the familiar language in order to get the job done quickly and with minimum effort, although the solution might technically be somewhat inefficient.

The best is often the enemy of good enough, and this applies very much here.

And if you are familiar with Perl, you may have already heard of TMTOWTDI: There is More Than One Way To Do It.

Answer 4

Please note that this is a personal opinion; take it with a grain of salt.

1. If the command fits within, say, 80 characters, use a one-liner. Long command lines are hard to work with. There's also the problem of recurrence, see #2

2. If you need to run the command(s) more than once, use a script. Else, use a one-liner, provided condition #1 is met.

3. This is very subjective, but yes, I see shell, Perl or awk as being my go-to tools for one-liners.
4. See #1, #2, #3.

Answer 5

I view and use a one-liner as a temporary development tool to edit repeatedly until it does what I want, or I understand how some subtlety of a sub-command works.

It then either gets noted (and annotated) in a text file on the subject I was investigating, or gets cleaned up into a script that gets put in my personal bin PATH, possibly for further refinement, parameterisation and so on. Typically, the one line will be broken up to more readable, even if no other changes are made, or I never use the script again.

I set my shell history to be over 5000 lines, with a separate history per terminal, and per login on a remote and so on. I hate not being able to find in these histories a one-line command I developed a few weeks back and didn't think I would need again, hence my strategy.

Sometimes, a whole group of commands are need to do something, like configure some hardware; at the end I copy them all out of the history, clean them up minimally, and add them to a shell script RUNME just as notes on what I did, but also so that they are almost ready to be used again by someone else. (This is why I find tools that only provide a GUI to configure them such a pain.) I find this an incredible gain in efficiency, as so often something you expect to do only once, has to be then done another 5 times...

Answer 6

I would want the people in my team to write scripts for whatever operations that may be required to be performed more than once (i.e. "workflows" or "pipelines"), and for whatever one-off task that is required to be documented (typically things like "modify certain things in some dataset to fix incorrectly supplied data" in our case). Apart from that, "one-liners" or scripts don't matter too much.

Failing to properly document workflows (as scripts or equivalent) makes it harder to introduce new staff on a project, and also makes it harder to transition people out of a project. It additionally makes any type of auditing difficult, and tracking down bugs may be impossible.

This is regardless of what language is used for programming.

Other workplaces may have similar/different customs or expectations, maybe even written down.

At home, you do whatever you feel like.

For example, I write scripts as soon as I do something non-trivial in the shell, like before submitting an answer to an U&L question, or whenever I need to test the individual components of a command or set of commands before running it "for real".

I also write scripts for repetitive tasks that I really want to do the same way every time, even if they are simple, like

• updating my OpenBSD system and all installed packages (this comes down to three short commands, and a handful of others for housekeeping, collected in a short script), or
• backing up my system to an off-site storage (essentially a single command, but again with quite a lot of housekeeping and the script also allows me to do diffs between snapshots etc., and it needs to work subtly different on different systems, and I run it from a cron job), or
• fetching mail (again, essentially a single command, but I want it to behave differently when called as a cron job and when I use it from the command line, and it shouldn't try to fetch mail under some circumstances, and it writes a short log message to a file).

I use shell functions (very seldom aliases) for convenience in interactive shells, e.g. to add options to certain commands by default (-F for ls) or for creating specialised variations of some commands (pman here is a man command that only looks at POSIX manuals, for example).

Answer 7

I must say I'm somewhat horrified by the implications of the first parts of the question. The Unix scripting languages are full-fledged programming languages, and programming languages are languages, meaning that they're just about as infinitely malleable and flexible as human languages. And one of the hallmarks of "infinite malleability and flexibility" is that there's almost never "one right way" of expressing something -- there are varieties of ways, and this is a good thing! So, yes, of course it's a matter of personal preference, and there's nothing wrong with that. Anyone who says there's only one way of doing something, anyone who expressed disdain about doing (or not doing) something one way or the other is probably being a pedant or a prescriptivist.

Once upon a time, my own ~/bin was full of "useful" little scripts I'd written. But I realized that most of them got used the day I wrote them, and never again. So the more time that goes by, the smaller my bin directory gets.

I don't think there's anything wrong with writing a script. If you imagine that you or someone else might use it again, by all means, write a script. If you want to "properly engineer" a supportable script for the sake of it, by all means, do so. (Even if nobody ever uses it, writing it is good practice.)

Reasons I don't write scripts as much any more (and, I guess, favor "one-liners"):

• bin directory clutter does have a cost. I don't put things there any more unless they really belong there.
• The scripting languages I use are languages that I use; I'm really facile with them by now. Retyping a one-liner whenever I need it doesn't feel like work; I don't feel a mandate to keep and save and use a script just to relieve the (re)typing burden. (Among other things, at some point the retyping burden becomes less than the memory burden of remembering what a script is.)
• Another reason retyping things doesn't feel like a burden is: command history. There are plenty of one-liners that I haven't enshrined as scripts, even though I use them every day -- but I don't have to retype them; I just recall them from history. In that way they're sort of poor-man's scripts or aliases.

Answer 8

Looks like I hold a minority view on this.

The term "script" is confusing, get rid of it. This is software you're creating, even if it's using solely bash and awk.

Within a team, I prefer to have code-review process enforced by a tool (github/gitlab/gerrit). This gives version control as a bonus. If you have multiple systems, you can add continuous deployment tools. And some test suites, if the target systems are important. I am not religious about these, but weigh the benefit against the cost.

If you have a team of admins, the easiest vim /root/bin/x.sh is mostly a disaster in terms of change-related communication, code readability, and cross-system distribution. Often one serious malfunction costs more time/money than the supposedly "heavy" process.

I prefer one-liners actually for anything that does not deserve that "heavy" process. They can be reused rapidly, with a few keystrokes, if you know how to use your shell history effectively; easily pasted between unrelated systems (e.g. different customers).

Crucial difference between unreviewed one-liners and the reviewed software ("scripts"): the responsibility is fully on you when you execute one-liners. You can never say "I just found this one-liner, I ran it without understanding, what followed is one-liner's author's fault" - you knew you are running unreviewed and untested piece of software, so it is your fault.

I feel I benefit from this duality (heavyweight approach vs lightweight), and setting the boundary between them at about one line of text works well enough as "the bar".

Some of my one-liners look terrifyingly long to you, but they do work effectively for me. As long as I grok them and I don't shove it onto more junior colleagues, it's all fine. The moment I need to share them - I go through standard software-development process.

Answer 9

I believe that most of the time the request for a "one-liner" is in fact a request for a "sound bite", that is:

In the context of journalism, a sound bite is characterized by a short phrase or sentence that captures the essence of what the speaker was trying to say, and is used to summarize information ...

People want and request for the shortest code that demonstrates a solution to the question asked.

Sometimes, there is no way to reduce an speech to a "sound bite" as well as may be impossible to reduce an script to a short "one-liner". In such cases the only possible answer is an script.

And, in general, a "sound bite" is never a good substitute of the whole speech. So, a "one liner" is generally only good to convey an idea or to give a practical example of that idea. Then, after the idea is understood, it should be expanded (applied) in an script.

So, write a "one-liner" to convey an idea or concept.

Write your general code as full scripts not one-liners.

Answer 10

Perl's one-liner is a kind or small art, where concision meet efficiency. They’re especially handy for quick file and text manipulations without writing boilerplate file‑handle code.

For sure, this is not limited to Perl, sed, awk, cut, mlr, jq, yq, xidel, xmllint, xmlstarlet and others are great for one‑off. tasks.

You can always write a Python or Node script to replace mlr or jq, but one‑liners are often much more concise and faster to write for simple operations.

Here are a few Perl examples I rely on.

print lines from 10 to 25

perl -ne'print if 10..25' file
awk 'NR>=10 && NR<=25' file

rename files like Screenshot foo bar 2025-10-11.png to 01.png 02.png 03.png ...:

rename 's/.*(\.\w+)$/sprintf "%.2d%s", ++$main::c, $1/e' -- ./*

compute the Nth day of the year

perl -MTime::Piece -se '
    CORE::say Time::Piece->strptime($date, "%d%b%Y")->strftime("%j")
' -- -date="11Oct2025"

URI unescape

perl -MURI::Escape -le 'print uri_unescape($ARGV[0]);' 'http://example.org/%20%40%50%55'

print all IPv4 from the input

ip a | perl -MRegexp::Common -lne 'print $1 if /($RE{net}{IPv4})/'

that one is just funny to make palindromes

perl -lnE 'say if $_ eq reverse()' /usr/share/dict/american-english

Answer 11

It's almost purely subjective.

The only advantage scripts have over one liners is that they can be nicely formatted, thus easier to troubleshoot and debug when something invetiably goes wrong.

The only advantage one liners have is that you do not need to put the code in a file, make the file executable and execute the file to run the code.

I suppose a case could be made for the portability of one liners (it's easier for someone to copy a one liner from the net into his terminal and run it than to download and execute a script)

I think really the main thing is just paranoia, possibly even justified paranoia. A conceptual fear of unaudited code or something along those lines.

One liners are inherently simple because people don't really make script sized one liners. Because it's a pain in the ass to work with huge one liners, when they exist it's usually as some kind of joke, or just to prove a point that it's possible rather than for practical reasons.

So when you're looking for how to do stuff on the net you are likelier to prefer one liners because you can in a matter of seconds look over the entire 'code and ensure that there's nothing obviously fishy in it. Then copy paste it to a terminal and execute it without the slightly more involved process I described earlier for executing scripts.

Whereas with a script that's say maybe 100 lines... I mean it's easy to do the same, trivially so, but it's intimidating for people who aren't used to it. Which would explain the strong preference for one liners.

I sometimes use the techniques used for creating one liners in my scripts too in fact, for formatting, to make it appear shorter and have a smaller line count. It's purely for aesthetics, some people hate it, I like it.

For instance instead of getting a string, setting it as a variable, processing the variable to remove parts of the string I don't want (typically with sed awk or grep), then passing that along to some function, I might just pass a one liner that gets and modifies the string straight to the function without setting the variable. Effectively passing a one liner as an argument to a function. I do this kind of thing a lot.

But when it comes down to it, as anyone who has any programming knowledge can verify, running the whole code in one line and running it in a nicely formatted script is ultimately the exact same thing. The only difference is to how the user interacts with the code, not how the code gets executed, to the computer it is the same code.

Which means, there is no right answer here. Just do what you prefer, what feels right, it doesn't truly matter. When people are asking for help with doing something as a one liner, something I've done quite a bit, it's just because they want to do the thing as a one liner, there's never as far as I'm aware a real practical reason for using one liners besides just simple convenience.

I often use the process of trying to convert some beefy chunk of code into a simpler one liner as a learning opportunity to optimize how I write my scripts, reduce the number of executions, and such.

Answer 12

You ask about "fear and disdain of scripts". This is due to the Q+A situation, where often the answer is saying: It needs this step and this, but I can also put it in one line (so you can copy paste it and use it as a long simple command).

You can sometimes only guess if the Q is better served by a quick and dirty copy paste solution, or if a "nice" script is exactly what the Q needs to understand.

A lot of the pros and cons here are true, but still they are missing the point. I would even say the definitions in the Q are not helpful.

The shell history files are "one liners", but still they are saved. The bash function operate-and-get-next (C-o) even lets you repeat them semi-automatically.

I hardly see the word function mentioned. That is the way to store both "scripts" and "one liners". And with a few keystrokes you can switch between both formats. A compound command can often fit both.

history -r file is the way to read one or many command lines (and comments) from any file, not just from default history file. It just takes some minimal organizition. You shouldn't rely on a large history file size and history search to retrieve (some) version of a command line.

Functions should be defined in a similar way. For starters, put thisfunc() {...} in a file "functions" in your home dir, and source it. Yes this is some overhead, but it is the general solution.

If you store every command line and every script variation in a separate file, it is a (theoretical, but objective) waste of filesystem blocks.

A one-liner has nothing quick and dirty by itself. It's more the copy-paste part that is bit frowned upon, and how we just rely on command history to save it for us.

---

@sitaram: your one liner really has un-onelinerish features: shebang line, newline, four utility calls - two of them sed "programs". I think the original perl script looked nicer and ran faster and did not waste any bytes by spreading out on 60 lines. And perl also lets you squeeze quite a bit.

For me, that is exactly the kind of one liner to avoid. Would you want to have that (pasted) on your command line? No, and then, if you store it in a file anyway (no matter script or function), you might as will invest two or three newline-bytes to make it look --- nice.

---

10 min. later: I just wanted to check if I can say "two sed programs" or of it is "two sed substitutions/calls". But sitaram's answer is gone. My reply still makes sense I hope.