This patch adds basic file name detection mode in hget, for example: hget -a http://9front.org/img/nix-on.jpg would be equal to hget -o nix-on.jpg http://9front.org/img/nix-on.jpg --- /bin/hget +++ /bin/hget @@ -2,7 +2,7 @@ rfork e argv0=$0 fn usage { - echo usage: $argv0 '[ -l | -o file] [ -p body | -P ] [ -r header ] [ -m method ] [ -b baseurl ] url' >[1=2] + echo usage: $argv0 '[ -l | -a | -o file] [ -p body | -P ] [ -r header ] [ -m method ] [ -b baseurl ] url' >[1=2] exit usage } s=0 @@ -34,6 +34,8 @@ case -b b=$2 shift + case -a + o=`{basename $2} case * usage }
> @@ -34,6 +34,8 @@
> case -b
> b=$2
> shift
> + case -a
> + o=`{basename $2}
> case *
> usage
> }
This assumes that the URL immediately follows the '-a' which it won't
in general. That aside, the idea probably doesn't work so well when
you have URLs with a query component either.
Can you mention a example?
i don't understand first one and simple URLs with queries in them worked
for me.
Alex Musolino wrote:
>> @@ -34,6 +34,8 @@
>> case -b
>> b=$2
>> shift
>> + case -a
>> + o=`{basename $2}
>> case *
>> usage
>> }
>
> This assumes that the URL immediately follows the '-a' which it won't
> in general. That aside, the idea probably doesn't work so well when
> you have URLs with a query component either.
>
Quoth mkf9 <mkf9@riseup.net>: > Can you mention a example? > i don't understand first one and simple URLs with queries in them worked > for me. > > Alex Musolino wrote: > >> @@ -34,6 +34,8 @@ > >> case -b > >> b=$2 > >> shift > >> + case -a > >> + o=`{basename $2} > >> case * > >> usage > >> } > > > > This assumes that the URL immediately follows the '-a' which it won't > > in general. That aside, the idea probably doesn't work so well when > > you have URLs with a query component either. > > > For an example of the first thing Alex brought up: hget -a -b http://www.example.com/videos ../images/image01.jpg The '?' and following is a query component: https://www.example.com/your.jpg?_dc=19594393
I like to use the plumber for this. Just type or snarf'n'paste preferred name on the end like this: http://9front.org/img/plumber.jpg→/tmp/plumber.jpg Then the plumb rule does the rest, complete with whatever whizzbang statusbars you like. Or you could type dl before the url and have a plumb rule that matches on something like dlhttps?://.+/([^/]+)([?#].*)? and then uses the $1 match as the filename, neatly evading the query thing too. umbraticus
unobe@cpan.org wrote:
> For an example of the first thing Alex brought up:
>
> hget -a -b http://www.example.com/videos ../images/image01.jpg
>
> The '?' and following is a query component:
>
> https://www.example.com/your.jpg?_dc=19594393
>
I have tried some URLs with queries with them
and haven't seen any which fails, why should they?
for the other issue, i think this version will do.
--- /bin/hget
+++ /bin/hget
@@ -2,7 +2,7 @@
rfork e
argv0=$0
fn usage {
- echo usage: $argv0 '[ -l | -o file] [ -p body | -P ] [ -r header ] [
-m method ] [ -b baseurl ] url' >[1=2]
+ echo usage: $argv0 '[ -l | -a | -o file] [ -p body | -P ] [ -r header
] [ -m method ] [ -b baseurl ] url' >[1=2]
exit usage
}
s=0
@@ -34,6 +34,8 @@
case -b
b=$2
shift
+ case -a
+ o=`{basename $$#*}
case *
usage
}
> I have tried some URLs with queries with them
> and haven't seen any which fails, why should they?
It’s not that they file but that file you write to disk has the query string in the name.
> It’s not that they file but that file you write to disk has the query string in the name.
Sorry. It’s not that they *fail* but that *the* file you write to disk has the query string in the name.
Quoth Alex Musolino <alex@musolino.id.au>:
> > It’s not that they file but that file you write to disk has the query string in the name.
>
> Sorry. It’s not that they *fail* but that *the* file you write to disk has the query string in the name.
take a look at RFC6266 for the filename param; we should probably use that
if it is present.
Alex Musolino wrote:
>> It’s not that they file but that file you write to disk has the query string in the name.
>
> Sorry. It’s not that they *fail* but that *the* file you write to disk has the query string in the name.
>
I can repro this with wget and OpenBSD ftp,
maybe that's a common issue?
> take a look at RFC6266 for the filename param; we should probably use that
> if it is present.
I think that would just create more problems. Now the target filename is hidden. You’d have to print out the name of the file it wrote for it to be available for further manipulation in a script, say.
Furthermore, what happens if the destination already exists? You can’t just overwrite it.
I think this -a may just be a bad idea. If you want to do this kind of thing in the privacy of your own $home it shouldn’t be hard to create a wrapper script that does whatever you want.
> I can repro this with wget and OpenBSD ftp,
> maybe that's a common issue?
Perhaps, but we’re not trying to be bug-for-bug compatible with these other programs.
a custom shell script wrapper does seem like the best option, since the user is the final authority on their own preferences. imo, > redirection obviates the need for more flags.
sl
> On Oct 16, 2022, at 4:03 PM, Alex Musolino <alex@musolino.id.au> wrote:
>
>
>>
>> I can repro this with wget and OpenBSD ftp,
>> maybe that's a common issue?
>
> Perhaps, but we’re not trying to be bug-for-bug compatible with these other programs.
>
>
>
Quoth Alex Musolino <alex@musolino.id.au>:
> > take a look at RFC6266 for the filename param; we should probably use that
> > if it is present.
>
> I think that would just create more problems. Now the target filename is hidden. You’d have to print out the name of the file it wrote for it to be available for further manipulation in a script, say.
>
> Furthermore, what happens if the destination already exists? You can’t just overwrite it.
>
> I think this -a may just be a bad idea. If you want to do this kind of thing in the privacy of your own $home it shouldn’t be hard to create a wrapper script that does whatever you want.
consider me convinced.