Re: bugzilla escalation process (is there one) ?

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

 



On Wed, 2006-08-09 at 14:36 -0700, Don Russell wrote:

> Is it unreasonable to expect that ftp exits with a non-zero exit code 
> when something goes wrong? (I was asking that it return the highest code 
> it received from the server... well-documented error codes specific to 
> the ftp protocol; return zero if the actual code is in the 2xx range 
> would be acceptable)

I'm not sure its unreasonable, but it is not clear to me that a
working client should report anything that it's counterpart
server does as its own error.  Exit codes normally relate
to the program itself. 

> I wanted to use the .netrc mechanism to provide a little script to ftp 
> the contents of a directory to a site. The ftp command is invoked by 
> another process (i.e. not a human using cli reading the text responses), 
> but that's useless when ftp always ends with zero.

If you control both ends, just use rsync over ssh or scp or something
where failure is implied by the completion of the command you issued.
Ftp was designed to be interactive with success/failure reported per
operation not overall.

> Yes, I can write some Perl code to do this, and not use the ftp 
> command.... but the ftp command is already available, the .netrc 
> mechanism suits my purpose in this application...

You can do it in perl code with Net::FTP, responding to the server
errors as you see fit.

> The only reason I'm pursuing this any further is because I feel "it is 
> the right thing to do". 

I'm not convinced that a server error has much relationship to
a client error.  For example the client clearly hasn't failed if you
ask for a file that doesn't exist.

> I've since found another solution to my problem 
> because ftp, as it is now, is of now use to me, except as a cli tool.

That's what it is for.  If you want to script it and know about
the server-side responses you'd need something like expect to parse
its output - and there are better approaches.

-- 
  Les Mikesell
   lesmikesell@xxxxxxxxx


-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux