feat: smart default download path + stdin/stdout support

[jason-rl]

Summary

• Optional download path: object download <id> [path] — when path is omitted, auto-generates from object name + content_type with smart extension inference. Use - to write to stdout.
• Stdin upload: object upload - --name <name> --content-type <type> reads from stdin. Also auto-detected when stdin is piped with no paths (e.g. echo data | rli obj upload --name foo --content-type text). Zero-byte pipes upload an empty object rather than printing the URL.
• URL-only upload: object upload --name <name> with no paths and no piped stdin creates the object and prints the pre-signed upload URL to stdout, enabling external upload workflows (e.g. curl -X PUT -T file "$(rli object upload --name foo)")
• processUtils async I/O: stdout.write/stderr.write accept string | Buffer (was string only), and stdin is now AsyncIterable<Buffer> — upload and download go through the mockable abstraction instead of process globals directly
• TUI improvement: Default download path in both list and detail TUI screens now infers extensions from content_type

Extension inference rules (case-insensitive)

Content type	No suffix	Mismatched suffix	Special
text	→ .txt	no change	—
binary	no change	no change	—
gzip	→ .gz	→ append .gz	.tar → .tgz
tar	→ .tar	→ append .tar	—
tgz	→ .tgz	→ append .tgz	—

This is the complement of adjustFileExtension() from runloop-fe PR #1714 — that strips extensions for mount paths (post-decompression), this adds extensions for download paths.

Test plan

• 40 unit tests for inferDownloadExtension and getDefaultDownloadPath pass
• 4 unit tests for 0-paths URL-only upload mode pass
• 9 unit tests for stdin upload (explicit - path and piped stdin auto-detection, including 0-byte pipes)
• 7 unit tests for download command (file path, auto-resolve, stdout, binary TTY warning, structured stderr output)
• rl object download <id> without path → verify auto-generated filename has correct extension
• rl object download <id> custom.out → verify explicit path still works
• rl object download <id> - → verify data goes to stdout; verify TTY warning for binary types
• echo "hello" | rl object upload --name test --content-type text → verify upload from stdin (no - needed)
• echo -n '' | rl object upload --name test --content-type text → verify 0-byte upload (not URL mode)
• rl object upload - --name test --content-type text → verify explicit stdin upload
• rl object upload --name test-url --content-type text → verify prints upload URL (no pipe)
• TUI: select download on objects with various content types → verify pre-filled path has correct extension

🤖 Generated with Claude Code

[dines-rl]

path - as a signifier is probably not a user friendly way to allow download to std out, maybe --stdout or something

[dines-rl]

Stdin support: object upload - --name --content-type reads from stdin (cannot be mixed with other paths)

this can be automatic with cat text.txt | object upload --name x same way password managers do cat password.txt | pulumi secret set

[dines-rl]

URL-only upload: object upload --name with no paths creates the object and prints the pre-signed upload URL to stdout, enabling external upload workflows (e.g. curl -X PUT -T file "$(rli object upload --name foo)")

i dont understnad this

[jason-rl]

path - as a signifier is probably not a user friendly way to allow download to std out, maybe --stdout or something

the - is already a precedent with many coreutils/tools. Although instead of a stderr warning if the content is binary, I can make it an error (even in the text case where the content is just generally very long in terms of lines (including wrapping from terminal width)).

Using a single hyphen (-) as a path argument is a long-standing Unix convention that tells a tool to use standard input (stdin) or standard output (stdout) instead of a physical file on disk. This is particularly useful for "piping" data between commands without creating temporary files.

Here are several prominent open-source tools that implement this convention:

1. tar (Tape Archiver)

The tar utility uses -f - to indicate that the archive itself should be read from or written to the standard streams.

Write to stdout: tar -cvf - /path/to/dir > archive.tar (Creates a tarball and sends it to stdout).

Read from stdin: cat archive.tar | tar -xvf - (Unpacks a tarball arriving via a pipe).

2. ffmpeg (Multimedia Framework)

ffmpeg uses the hyphen to handle raw media streams in a pipeline.

Example: ffmpeg -i input.mp4 -f mpegts - | some_other_tool

In this case, the final - tells ffmpeg to output the muxed data to stdout. For input, you can use -i -.

3. curl (Data Transfer)

While curl writes to stdout by default, the -o (output) and -T (upload) flags can explicitly use the hyphen.

Upload from stdin: echo "hello" | curl -T - [http://example.com/upload](http://example.com/upload)

Write to stdout: curl [http://example.com](http://example.com) -o - (Redundant but functional).

4. diff (File Comparison)

diff can compare a local file against data coming from a pipe by using -.

Example: ls /dir1 | diff - /dir2_contents.txt

This compares the output of ls (stdin) against the text file provided as the second argument.

5. pandoc (Document Converter)

pandoc is the "Swiss Army knife" of document conversion. If you don't provide an input file, it defaults to stdin, but you can be explicit.

Example: echo "# Hello" | pandoc -f markdown -t html -o -

This reads the string from stdin and prints the HTML conversion directly to stdout.

6. jq (JSON Processor)

jq uses the hyphen to explicitly define where the JSON data is coming from when multiple arguments might confuse the parser.

Example: cat data.json | jq . -

Stdin support: object upload - --name --content-type reads from stdin (cannot be mixed with other paths)

this can be automatic with cat text.txt | object upload --name x same way password managers do cat password.txt | pulumi secret set

good idea actually (will change so that it won't print the URL in this case and actually work)!

URL-only upload: object upload --name with no paths creates the object and prints the pre-signed upload URL to stdout, enabling external upload workflows (e.g. curl -X PUT -T file "$(rli object upload --name foo)")

i dont understnad this

in our website, when you create an object, it doesn't ask you for the file to upload only until you press the create button. Then it gives you a pre-signed upload URL, or you can upload the object instead. rl-cli doesn't support pre-signed upload URL, so I figured that not specifying a input file to upload means one wants to do the upload URL way