search

ewtoombs / todd

MIT License
0 stars 1 forks source link

Serving a single file #1

Open victorz opened 1 year ago

victorz commented 1 year ago

The AUR package description of this piece of software says it's "More generic and elegant than woof."

Let's take a look at some scenarios that I'd like to see working from something more generic and elegant than woof:

Serving a single file:

todd 5000 /etc/fstab

Crashes when client connects.

Serving the result of a pipe command:

todd 5000 'cat /etc/fstab | nl'

Crashes when client connects.

Serving todd's own stdin:

cat /etc/fstab | nl | todd 5000

Fails with usage output (since no command listed as argument(s)).

At least serving a single file would nice if you didn't have to use a separate command: todd 5000 cat /etc/fstab...

Hopefully this would be possible to accomplish somehow! :pray:

ewtoombs commented 1 year ago

Nothing wrong with todd 5000 cat file.

ewtoombs commented 1 year ago

For pipes, see https://github.com/ewtoombs/todd/issues/2

ewtoombs commented 1 year ago

Thankyou for your interest.

ewtoombs commented 1 year ago

Serving stdin is an interesting idea. See #3

victorz commented 1 year ago

Thank you for your comments! And I appreciate the acknowledgement of #3. That would be awesome -- a real UX improvement.

Nothing wrong with todd 5000 cat file.

I mean, sure, there's nothing "wrong" with it, but it's not "more elegant" than woof's behavior IMO. It's more cumbersome.

But it's fine -- serving a single file as well as #2 can be made simpler/more elegant using a shell script wrapper, especially in fish. I'll get right on that to scratch my own itch. I'll probably be enabling the different behaviors using a simple flag, like -c ("--command"), which should be all we need.

  1. No -c flag: serve the file argument
  2. -c flag provided: run the command argument in a shell and serve the output (solves the pipe scenario as well as simple file arguments that are executable that we want to run)
  3. No argument: serve standard input (yet to be implemented, as you mention)

IMO this is the most elegant and idiomatic behavior.

Any interest in having such a script submitted here? Otherwise it'll go in my private collection. :blush:

ewtoombs commented 1 year ago

I consider todd 5000 cat file to be more elegant because a single interface covers both cases of serving files and serving commands. That and having to add cat to the arguments does not make the command more difficult to use or to script with.

However, if serving of files is given a special case, then the file name, mime type, and size can be added to the server's response headers. That requires more software, which is less elegant as well. But the added value of good response headers may be worth it. (I actually already add a file name header whenever the command is cat, but I've decided this is a bad idea. This could end very badly if somebody is using cat in an unexpected way.)

I would use -f though, for the file case, and leave the command case as the default. Better backward compatibility. I don't have scripts that use todd, but I use todd a lot and I will forget to add the -c for like the first month lol.

todd 5000 tar c directory  # command serving
todd 5000 -f fancy-lad.jpg  # file serving

If you can add a -f switch, and give the response some fancy headers (mime type, file name, size), the pull request would be welcome. Oh, and for bonus points, responding to byte range headers in the request would be extremely awesome.