Re: [dev][sbase] seq possible bug

2013-07-01 Thread Galos, David
> Revised patch: this one also matches the usage to the manpage, fixes > the troff warning in the manpage, and adds a SEE ALSO section to the > manpage. I have just applied this, the bug should be fixed.

Re: [dev][sbase] seq possible bug

2013-06-20 Thread Galos, David
Revised patch: this one also matches the usage to the manpage, fixes the troff warning in the manpage, and adds a SEE ALSO section to the manpage. sbase-fix-seq.diff Description: Binary data

Re: [dev][sbase] seq possible bug

2013-06-20 Thread Galos, David
> Indeed, to quote the Plan9 manpage: "ARGF must be called > just once for each option argument. " I will submit a patch making use of > a temporary variable. In addition to adding and using a temporary variable to fix the ARGF() problem, I also shrunk the switch on argc to be shorter and more con

Re: [dev][sbase] seq possible bug

2013-06-20 Thread Galos, David
> Printing the format string in validfmt() shows that it is correct. > Printing after 'fmt = ARGF();' in line 33 shows clipped format. I have > no idea how ARGF works and cannot troubleshoot past that. Thanks. Indeed, to quote the Plan9 manpage: "ARGF must be called just once for each option argum

[dev][sbase] seq possible bug

2013-06-19 Thread Jesse Ogle
On master branch for sbase, it seems that on the seq command the format string (option -f) is having the first character clipped off. Sample below. ./seq -f "%04g" 3 04g 04g 04g ./seq -f " %04g" 3 0001 0002 0003 Printing the format string in validfmt() shows that it is correct. Printing after 'f