bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] wcat?


From: Tim Rühsen
Subject: Re: [Bug-wget] wcat?
Date: Thu, 20 Nov 2014 20:05:07 +0100
User-agent: KMail/4.14.2 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; )

Am Donnerstag, 20. November 2014, 17:22:24 schrieb Dagobert Michelsen:
> Hi,
> 
> > Am 20.11.2014 um 08:55 schrieb Ángel González <address@hidden>:
> > 
> > On 20/11/14 07:34, Darshit Shah wrote:
> >> And talking about legalities, I'm hoping you already have signed the
> >> assignment papers because otherwise that's even more work, before we can
> >> add this to the source. :-)> 
> > Come on, that's not needed for trivial changes :)
> > The given shell script is a perfect example of trivial patch.
> > 
> > And regarding the "required options", I would keep the
> > parameter-checking cruft to a minimum.
> 
> I would consider this worse than not including it because if you don’t do it
> right you get all sorts of problems. My main concern is the it should
> hardcode to $(bindir)/wget as passed to configure or e.g. /opt/csw/bin/wcat
> with /opt/csw/bin not in the path would result in invoking the wrong (or
> none at all) wget. This requires substitution during configure and not
> being put in contrib.

From what I read here and in this thread, having a script seems to be more 
work than just building it into the Wget code.

The Unix way: wget checks if the name of the executable is 'wcat'.
Doing so after all options have been processed, 'wcat' could easily check if
e.g. -O has been given on the command line (or the config file) and stop with 
an 
error message (or whatever is appropriate).

It's easier to maintain for us developers. I guess.

Just an idea. I am not going too deep into this discussion, too much work left 
for next two weeks ;-)

Regards, Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]