curl, new long option '--out-null'

[icing]

Add a new commandline option --out-null that discards all response bytes into the void. Replaces non-portable use of '-o /dev/null' with more efficiency.

Feature earliest for 8.16.0

Update: fixed it to work "per url", as --output does. Added test755 to check this behaviour.

[arbrauns]

Personally I'm not a big fan of the name.

• Presumably the "null" part refers to /dev/null, which as you say is non-portable, so the meaning might not be familiar to users of systems that don't have /dev/null.
• Upon reading the title I first assumed it was something about separating output elements with NUL bytes (c.f. grep --null).
• Additionally, the long option for -o is --output, not --out, I'm not sure if shortening it here is a good idea.

How about something like --discard-output or --output-discard?

[bagder]

Some people (on Mastodon) asked about reasons for this new option. Discarding the output is interestingly a fairly common thing to do for curl users.

• it makes command lines more portable (to copy between Windows <=> Linux for example)
• several users actually asked for this independently of each other (in the curl user survey)
• it is a (quite significant) performance boost for some cases

[vszakats]

Maybe sticking with the existing root of --output, and use the name --output-null, to make grepping / recognizing it easier? Or another word instead of null, though null sounds quite universal (to my ears at least). On Windows it's called NUL.

null has the added benefit that a grep would also bring up all existing /dev/null instances on *nix systems and a -i nul would pick up all instances on all operating systems.

[Baa14453]

Personally I'm not a big fan of the name.

* Presumably the "null" part refers to `/dev/null`, which as you say is non-portable, so the meaning might not be familiar to users of systems that don't have `/dev/null`.

The concept of NULL is also prevalent within Windows, for example PowerShell has an identicallly named function Out-Null.
I think it more relates to the concept of nullifying data, which is universal, rather than specifically /dev/null.

Personally I prefer --out-null.

[icing]

I have no great beef into the option name. I like to have the prefix --out-* or --output-*and I would object to
--output-discard-response-bytes-from-the-transfer.

[krono]

I like the idea.

I think --output-none is also a viable candiate that does not assume the Unix /dev/null idea; or --no-output for that matter.
Also, --gobble would be a fun name. (It comes from the TeX world, where \gobble is used to "eat up" its argument instead of acting on it. (which has to do with TeX being a Macro system and generally using methapors related to eating (but I quite like it )))

[dfandrich]

Bikeshedding time! I figured there must be lots of programs out there that have options that do something similar so maybe there's a "standard" name that could be used. I ended up not finding all that many, though, probably because suppressing the primary output of a program isn't that generally useful unless there is a side effect (e.g. files written to disk) or some other out of band means to get the result of running the program (e.g. stderr or exit code). These are a few Linux programs I found along with their options to suppress normal output (where the normal output is the primary output of the program and not just something like status or progress messages):

• fc-list: -q
• grep: -q, --quiet, --silent
• groff, troff: -z
• onsgmls: -s, --no-output
• pdfgrep: -q, --quiet
• pidof: -q
• systemd-creds: --quiet, -q
• tidy: -errors, -e (i.e. focussing on the side-effect that results when primary output is suppressed)
• xmllint: --noout
• xz: -t, --test (i.e. focussing on the side-effect that results when primary output is suppressed)

The Art of Unix Programming says using -q "is very common", which shows above. For curl, -q is already used but --quiet is a possibility, though it could be confused with --silent. And, it won't actually produce a completely quiet output unless --silent is also used.

I like --no-output, which has precedence in the list above, matches the style of existing curl options (e.g. --no-clobber, --no-keepalive) and, importantly, is the negation of the --output option which is already the option that controls curl output.

[vszakats]

--no-output sounds like a sensible alternative!

[bagder]

--no-output

The only little nit about this is that we only allow a --no- prefix for boolean options to invert their meanings, and --output is not a boolean option so it would need to be a special case.

[icing]

--no-output

The only little nit about this is that we only allow a --no- prefix for boolean options to invert their meanings, and --output is not a boolean option so it would need to be a special case.

My thoughts as well. Currently --out-null is a bool option, so one can revert it with --no-out-null.

But we can break all the rules and roam the command line space free!

[bagder]

@icing: how about curl https://example.com/ https://example.com/ --out-null -o dumpit ? I think the current implementation doesn't support this?

[icing]

@icing: how about curl https://example.com/ https://example.com/ --out-null -o dumpit ? I think the current implementation doesn't support this?

if -o file comes after --out-null, the output discarding is switched off again. Is that not what users would want?

[bagder]

if -o file comes after --out-null, the output discarding is switched off again. Is that not what users would want?

Well, we get to decided that now, don't we? 😄

In my head, the command line: curl https://one https://two/ --out-null -o dumpit would discard the output for the first transfer (one) and write the output for the second one (two) to the file dumpit. As that is what replacing --out-null with -o /dev/null would do.

The alternative, which I think is what you have implemented now, is that --out-null is used for all provided URLs. Which makes it a little more like an alias for > /dev/null.

[icing]

In my head, the command line: curl https://one https://two/ --out-null -o dumpit would discard the output for the first transfer (one) and write the output for the second one (two) to the file dumpit. As that is what replacing --out-null with -o /dev/null would do.

The alternative, which I think is what you have implemented now, is that --out-null is used for all provided URLs. Which makes it a little more like an alias for > /dev/null.

Ok, that was not my intention. It should only apply to one url, I think. Like -o does.

[tlhackque]

Why not focus on the effect rather than the mechanism? --discard. Or if you want a very-long-switch-name, --[no-]discard-output. (Though the opposite of discard is keep :-)

/dev/null,, windows NUL, VMS NLA0:, RSX NL:... are all mechanisms, not effects. That they have similar names is an accident of history.

[Paul-Gilmartin]

I like to be able to name --etag-compare and --etag-save with names derived
from %{filename_effective}.
I do this with a trial execution directing --output-dir ReadOnly, avoiding most
of the bandwidth cost of a large file. Will %{filename_effective} continue
to operate with --output-null?

[grgoffe]

Howdy,

I do a LOT of website scrubbing and am usually blocked by overly aggressive authentication... even with the options currently available. Web servers can get a TON of information about the "originator" of requests and can, with minimal effort, tell if the requestor is a person or a crawler. I think this could be dealt with by curl in "pretend to be a person" mode. Will this new quiet/silent/null option help with this? This seems to be, IMO, a JavaScript "problem". Would this option help me?

George...

[Paul-Gilmartin]

On 7/4/25 12:36, grgoffe wrote: effort, tell if the requestor is a person or a crawler. I think this could be dealt with by curl in "pretend to be a person" mode. Will this new quiet/silent/null

... Are you proposing that Curl make honoring "robots.txt" optional?

…

-- gil

[grgoffe]

Paul,

Hmmmmm...

Good point. I hadn't thought of that.

Let me think on the idea that "pretending to be a human" while obeying the robots.txt directive and it's ramifications.

THANKS,

George...

[ethanalker]

My thoughts as well. Currently --out-null is a bool option, so one can revert it with --no-out-null.

What would the effect of inverting it be with the new behavior of acting per-url? Would it be the same as telling the second url to go to stdout? And if there's only a single url would it just revert the previous option?

I'm not sure how invertible per-url boolean options should work or do work now, but it might be something to think about.

[icing]

My thoughts as well. Currently --out-null is a bool option, so one can revert it with --no-out-null.

What would the effect of inverting it be with the new behavior of acting per-url? Would it be the same as telling the second url to go to stdout? And if there's only a single url would it just revert the previous option?

I'm not sure how invertible per-url boolean options should work or do work now, but it might be something to think about.

The choice of bool for the option was a mistakes and is now corrected. It works now in as an alternative to --output and is per url. So it becomes a true shortcut for -o /dev/null.

[MasterInQuestion]

    Would it be sensible to extend "--out-null", to auto-apply for every unspecified out destination?
    (whatever without interpreted destination otherwise; so assumed "-" STDOUT)

    I find it wieldy for alike situations:
    curl -A '' -v -Z --out-null --connect-to 'www.ibm.com::23.41.131.248' 'https://www.ibm.com/docs/'{'022d7839fbf0b01f1279','0c7e37865f4bb741d719','144035d867f964f2c13d','160c450b41a6dfc1bebe','19239848cb5cdf02953e','1ac9d0b721a47c618f27','22f2f7f20d522f25d8ec','32a6fcddf51918f011f5','3fb99cf388da08c31bd7','42c5469340604f5e79d5','4c3ed2a3f44451a96594','578aae4082fb12898fe3','5e1440da12d78046c31a','64e1054a50262b9083ab','6557a3c33c4218db6066','6956fe0f5e625049f7e2','6bdf3ec568a6634a4aea','6d9b6411704ee0e26f31','723a4b364f38da1e93e0','729e5174c878b0a30035','74025371289e2bab9590','8212ca4bb829a5d9f858','88cb07ee53507d19f992','8af6b3d1e1a4ac4fdd49','8bbf2e3b118b1732ea16','957995d81ad3284f963f','983c50a737da66c0bd02','987d18f198bd7d9fa265','9924e57202230ba397b0','a34802c95c44f5903e18','a81d5c10cd640839a4b8','aa343b4fcab1658acc56','b0ec1af29941e0f52305','bfefc1c5dd4c689b4f0f','c26797e2920f701bf68f','c781dd3e68cf4db696e2','c8cf918de7d9deffd15c','cacfd1d7dbd14067b970','cd9a0204454ff0e22880','cf8cdfc9a1ead9d332f5','d69d5111a1f16e74d2fb','e5317022888823405337','e7c487ed0bd3af889f66','f31b6425f37c2b71c3fc','f968050d6a8297e66619'}'.woff2';

    Adding "--out-null-all" maybe unnecessary? (redundant)
    The optimal logic may be:
    For all URL (if any) after [1] "--out-null": assume NUL destination (instead of STDOUT).
    Else: assume NUL destination for every destination unspecified (as top).
[ [1]
    (or before) Precisely, depending on whether the 1st URL:
    ; appears before/after the 1st destination specifier.
    E.g. "${URL} -o ${Destination}"; the postfix-out.
    "-o ${Destination} ${URL}": the prefix style.
    .
    Sensible commands typically do not mix the 2.
    (that's as if mixing Big Endian with Little Endian) ]

    Or maybe "--def-out ${Destination}" actually needed? (instead of assuming STDOUT)
    But seemingly much accomplishable with shell.
[ ^
    Nevertheless for reference:
    "-": STDOUT
    "%": STDERR
    ".": NUL ]

[sergeevabc]

-o nul vs --out-null on Windows?

[jay]

-o nul vs --out-null on Windows?

Yeah it does the same thing

https://curl.se/docs/manpage.html#--out-null