Hello, I have a need to enhance the tftp client to redirect the data to stdout. The enhancement will include a command line switch and adjusting the client code to be quiet and write to stdout instead of a file (currently default) The only other alternative is using curl, but the curl tftp subroutine does not do proper error checking and skips over blocks of data when an error occurs (we are talking udp, so this can happen more often the larger the tftp data stream is). I would like to give something back so o?nce I make this change, where can I push the changes to? Thanks, Mickey J. Malone mickey.malone at me.com
On 01/27/2012 07:47 AM, Mickey J. Malone wrote:> Hello, > > I have a need to enhance the tftp client to redirect the data to stdout. > The enhancement will include a command line switch and adjusting the > client code to be quiet and write to stdout instead of a file (currently > default) > > The only other alternative is using curl, but the curl tftp subroutine > does not do proper error checking and skips over blocks of data when an > error occurs (we are talking udp, so this can happen more often the > larger the tftp data stream is). > > I would like to give something back so o?nce I make this change, where > can I push the changes to? >Posting patches (or pull requests) to this mailing list works well. Typically in Unix this is done by specifying a single dash (-) as the output file name, it would be good to keep that convention. -hpa
hpa, Attached is the patch file. I stuck with the current defaults (write to file) and added a -B switch (short for Batch mode). If the -B switch is present, then so does the -c command or we will notify the user. I also moved all the tftp client output to stderr to keep file integrity during verbosity, updated the spec, and updated the man page. So basically, this works and is somewhat my use case: tftp -B -m binary 127.0.0.1 69 -c get intiramfs | gzip -dc | cpio -id -- Mickey -------------- next part -------------- A non-text attachment was scrubbed... Name: tftp-hpa-stdout.patch Type: application/octet-stream Size: 18971 bytes Desc: not available URL: <http://www.zytor.com/pipermail/syslinux/attachments/20120129/10d6c187/attachment.obj> -------------- next part -------------- On Jan 27, 2012, at 11:53 AM, H. Peter Anvin wrote:> On 01/27/2012 07:47 AM, Mickey J. Malone wrote: >> Hello, >> >> I have a need to enhance the tftp client to redirect the data to stdout. >> The enhancement will include a command line switch and adjusting the >> client code to be quiet and write to stdout instead of a file (currently >> default) >> >> The only other alternative is using curl, but the curl tftp subroutine >> does not do proper error checking and skips over blocks of data when an >> error occurs (we are talking udp, so this can happen more often the >> larger the tftp data stream is). >> >> I would like to give something back so o?nce I make this change, where >> can I push the changes to? >> > > Posting patches (or pull requests) to this mailing list works well. > > Typically in Unix this is done by specifying a single dash (-) as the > output file name, it would be good to keep that convention. > > -hpa >
The existing code does not support it from my initial tests. It just saves the output off to a file called "-". I will look into this. Keeping that convention is cleaner. How do you feel about moving all error/info output to stderr? This will leave stdout clean, which is needed if the data is being streamed to stdout or else it will get dirty. -- Mickey On Jan 27, 2012, at 11:53 AM, H. Peter Anvin wrote:> On 01/27/2012 07:47 AM, Mickey J. Malone wrote: >> Hello, >> >> I have a need to enhance the tftp client to redirect the data to stdout. >> The enhancement will include a command line switch and adjusting the >> client code to be quiet and write to stdout instead of a file (currently >> default) >> >> The only other alternative is using curl, but the curl tftp subroutine >> does not do proper error checking and skips over blocks of data when an >> error occurs (we are talking udp, so this can happen more often the >> larger the tftp data stream is). >> >> I would like to give something back so o?nce I make this change, where >> can I push the changes to? >> > > Posting patches (or pull requests) to this mailing list works well. > > Typically in Unix this is done by specifying a single dash (-) as the > output file name, it would be good to keep that convention. > > -hpa >