Make it support PUT instead of POST with a file form field and the command becomes simplified to:

    curl -T filename http://curl.io/send/abc123

Without knowing the hash, it might be nice to just:

    curl -F "@file=/path/myfile.tgz" http://curl.io/send

and get the hash returned with a url.

I'm always using transfer.sh. It will return a filename that can be shared. For example "curl --upload-file /tmp/test.txt http://transfer.sh/hello.txt" will return http://transfer.sh/6t9me/hello.txt.

Oh, and dropping files on the page will just change it into a download link.

Couldn't find any feedback form on the site, so I guess I'll post it here. Seems there's a small bug in the way the time, dispayed in the console, is calculated.

FilerCtrl uses:

  var c = new Date;
  a.date = c.toDateString() + " " + ("0" + c.getUTCHours()).slice(-2) + ":" + ("0" + c.getUTCMinutes()).slice(-2) + ":" + ("0" + c.getUTCSeconds()).slice(-2);

Which does not respect the current timezone.

I suppose it could be fixed by replacing

  c.getUTCHours()).slice(-2)

with

  (c.getUTCHours()).slice(-2) + (c.getTimezoneOffset() / 60))

Although you'd probably be better of using a library like http://momentjs.com/.

Thanks for the feedback, indeed I didn't want to use momentjs to overload the speed of the site, but I didn't notice for that mistake, thanks I appreciate :-)

Hey everyone, don't forget that copying commands from web sites and pasting them into a terminal window can be very dangerous http://thejh.net/misc/website-terminal-copy-paste

So paste into a text editor first is what you're saying?

I far prefer this, it uses filepicker as it's backend.

https://github.com/uams/geturl

While I'm doing command line file sharing, why not just directly transfer a file to my peer with netcat?

Server:

    $ cat hugefile.ext | nc -l -p 9999

Client:

    $ nc server.ip 9999 > hugefile.ext

We tend to forget how the network is built, and how easy it is to use it with the right tools.

Ah, a candidate for the useless use of cat award.

The first command can be given more easily as:

  nc -l -p 9999 < hugefile.ext

(which also mirrors the logic of the second, modulo nc's idiosyncratic argument syntax)

The cat version much more clearly represents the flow of data. We read left to right, it makes no sense to me to have data flow written right to left (and only for input files, while output files read left to right).

When building commands up from basics, it makes much more sense to start with cat. I will typically cat the file to see it's contents, then modify the command with a pipe to another program, and make keep adding processing steps to the end of the pipeline. Your < inputfile.txt notation completely breaks this model.

Just because you read something on a webpage that one time doesn't mean it is the one true way.

No, it makes much more sense to start with the command that is to process the file. Most commands take a command line argument to specify which file to process. This mirrors the redirection syntax perfectly:

You say:

  grep haystack needle.txt

or:

  grep haystack < needle.txt

whereas this is more convoluted:

  cat needle.txt | grep haystack

As a bonus the syntax looks the same for output redirection:

  sort < infile.txt > outfile.txt

whereas this is not as readable:

  cat infile.txt | sort > outfile.txt

What "makes sense" to you doesn't always to other people. In this case it's trivial, but it's a nightmare to debug larger scripts when there are lots of unnecessary redirections and if statements.

Shell scripts may be one-offs, but they tend to linger. It's not unwise to spend a few extra moments to make them readable and follow best practice. It is code after all.

(Also; a bit silly with the personal attacks.)

While I do agree with you, I think a common "gotcha" is in dealing with port forwards and firewalls.

Of course, NATs will break this type of scenario, but that can easily be solved with SSH tunneling into an accessible server.

Reverse tunnelling is more useful for this sort of scenario. Then the other person can connect to the remote server port and it'll reach you.

How do you identify a particular file ?

Also, HTTP is more accessible than raw TCP (you can use it from the browser)

Great idea but where I'd find value in something like this is for securely transferring files to people who, presumably, are somewhat clued. If I needed to do that, doing it without SSL seems counter productive (as has been pointed out). Additionally, while the four hour deletion is nifty, were I building this (could be a fun toy to hack together), I'd like a settable timer or download count. The comment about auto generating to URI path is spot on too. Sure, it would be nice to be able to choose but in many cases, a randomized path is ideal.

Again, cool toy and a fun idea but...

Too bad the code isn't available so I could hack it up a bit. I've saved this, in case bored and want to give it a try on my own some time.

You might be interested in this project I worked on https://github.com/abemassry/wsend-gpg it's end to end encryption, there's no settable timeout but there is a delete command so something like what you're saying might be possible.

I've already posted below but wanted to share this with you incase you're interested.

Hey, thanks for your feedback. A gpg encryption help has been added, you can check this out.

Awesome!

Seems many new ideas around file sharing recently. To name a few:

- https://popbox.io

- https://nfil.es

- https://wsend.net

I wonder what their file storage limits are. Can I send them /dev/random ?

My guess is 5GB; the maximum size of a single S3 put.

Actually it's 5GB, but it can be more if you seems that can be useful for everyone.

Apart from parsing a HTML page (e.g. curl http://curl.io/), how exactly are you suppose to get a key (from terminal/ssh)?

Looks like you can re-use the keys.

Hello everyone,

Thanks for all these feedbacks!

I have considered most of them.

Well, as I can see the most of you are worried about the security, that I understand.

So I've just added little help with a GPG encryption right from your terminal before sending the file.

I think this is the most important things I can make right now, while I do not plan to install SSL certificate given that I don't make money with this site, and the server cost is enough.

But if some of you, guys, are interested in more professional features, let me know, we can discuss about it.

Cheers!

dizda

why not startssl? you will get the SSL certificate for free

What exactly is the point of this? I'm seriously asking. What's a scenario in which Curl.io would be useful?

In my case, I going through several SSH (My Terminal => Bridge SSH => Target SSH) to get for example a backup. It's just easier for me to get the file back with curl.io instead of using something like SCP in this kind of situation.

Yikes, this should really be accessible only via HTTPS.

Copying commands from untrusted websites (or insecure connections) and pasting them into your terminal is not a good idea:

http://thejh.net/misc/website-terminal-copy-paste

That's not really relevant to what's going on here. This isn't some script you're blindly downloading/executing from an untrusted source, and it's certainly not a phishing attempt with a seemingly innocuous URL that is actually malicious once you copy it.

You can just `man curl` and find out exactly what's going on here. (http://unixhelp.ed.ac.uk/CGI/man-cgi?curl, scroll down to the bit on "--form", and check out the example) I think curl.io, the service, merely accepts this form data and stores the file on their servers, allowing you access. But you should easily be able to point at your own HTTP server and do all the same stuff. I don't see any "magic" here, other than a little web app that's responsible for taking in the data and writing whatever that data is to a given filename.

It is absolutely relevant. Did you check the link I posted? I understand completely what's going on here, and the important part is that the website is inviting you to copy a command from the website and paste it into your terminal.

Now, even if you're OK with giving curl.io your files and trust it enough to not insert malicious commands into the command you're pasting (see link from my GP comment), since the connection is on clear text, anyone between your machine and curl.io can in theory modify the command text you're invited to copy-paste, and inject malicious commands of their choosing.

I think the poster above you meant that someone could change the command to a malicious one if they found a security hole.

Don't know about you, but an SSL certificate does nothing to increase my level of trust of a website.

Without TLS, absolutely anyone along the link (not just curl.io) can inject some BS into your command line if you choose to copy-paste.

If you don't trust curl.io, fine. But without TLS the list of people you need to trust is not only curl.io, but everyone else in the tubes too.

Or just yourself. As it really should be.

Hey, I'm not sure that the SSL certificate will change something in the trust of the website, because the file will be hold by the website anyway. So according to me, I think you have to encrypt your file before sending it to the server, that you'll be sure to be the only one who can read your file (and other people who you give your passphrase).

I've updated the website with gpg encryption w/ passphrase FYI.

you're right but it should increase the level of trust along the way, no? or do I not undestand SSL correctly?

While active attacks are still possible, TLS prevents passive attacks (eg: eavesdropping).

Everything has to be 100% relayed via a central server. Sigh.

Not your fault of course. We've all lost kittens to NAT.

IPv6 will get rid of that nasty NAT, fortunately, and we can go back to true p2p transfers.

I was trying to do something like this to make it a bit easier to use:

#!/bin/bash

X=$(cd $(dirname "$1") && pwd -P)/$(basename "$1")

curl -F "file=$X" http://curl.io/$2

Did you really name a variable "X"?

Guilty.

I use cloudapp for sharing files and they have a convenient ruby gem for command line use: https://github.com/cloudapp/cloudapp.rb

Typing in file name within a page just to generate URL seems clunky to me. I believe, you can provide URL generation from a REST API that can be called from command line.

Using curl!

For something similar check out: https://wsend.net

What were your difficulties with other storage?

S3 is as easy as:

s3cmd put FILE [FILE...] s3://BUCKET[/PREFIX]

Dropbox is automatic, just move a file to a local directory. They have CLI tools, though. If you want the public url, it's just:

$ ~/bin/dropbox.py puburl ~/Dropbox/Public/file.zip

If you don't want dropbox running all of the time, just use the 'start' and 'stop' arguments to dropbox.py.

References: http://s3tools.org/usage

http://www.dropboxwiki.com/tips-and-tricks/using-the-officia...

There were 2 issues, one copying the script onto every machine and the second one related to login credentials. Some scripts needed an authentication file and others need it on prompt. Unfortunately keys(both S3 and dropbox) are not handy all the times.

Agreed. The web UI reacted almost instantly when I hit enter in the terminal.

I'd want an interface to destroy the file immediately then fallback to the 4 hour auto-delete.

Also some serious details about the author and security before I'd actually consider sending anything mission critical.

Thanks for your feedbacks! In fact, I developed this tool just to get some help in my everyday work, because I'm used to connect to several SSH at the same time of my customers (My Terminal => Bridge SSH => Target SSH), and it can become a little bit confused with SCP command..! This kind of tool helped me a lot, and I choose to share it with other DevOps/SysAdmin.

@beeskneecaps: I never thought about the link to destroy immediately the file, I'll put it tomorrow, thanks :)

I'm the author, @dizzda on twitter, you'll get additional informations about me.

About the security, i'll be honest, it was just to see if the concept can be interesting for other people, the only security (yet) is that the file will be auto-deleted in 4 hours. Files are hosted on a private dedicated server. So yeah, you can always take care to encrypt yourself your file before send it there.

If many people are interested to use this tool in a more professionnal-way, I can take some time to think about it... Anyway, it's just a real pleasure to hear your feedbacks guys! Please do not hesitate!

Cheers, dizda.

Some terminal emulators support in-band file transfers using zmodem. SecureCRT does this.

iTerm: http://grack.com/blog/2011/10/26/automatic-file-transfer-in-...

Certainly, there is no need to put <span> tags inside <div> tags, that is invalid HTML5 or at least according to W3C validator.No offense meant to the author. Peace!

I don't think there is anything wrong with span inside div. The other way is a problem though.

But http://validator.w3.org doesn't give me errors about spans or divs. It just gives errors with attributes.

This looks great!

You should also provide a copy to clipboard button.

This is considered :)

whaaat.

does anyone else think this is slightly suspect and/or bogus?

OF COURSE you should assume the owner of the website can read any file you send, but besides that it seems like it's fine.

I like how this was downvoted to hell.

How would it be? It's just using cURL to send a file to a URL.