bug#12482: Feature Request: support for int, octal, and hex types in seq --format
Craig Sanders wrote: seq only supports floating point types like f and g in the --format string. Other types, including i,d,o,u,x,X would also be useful. e.g. seq --format 'prefix%02isuffix' 1 50 to print zero-padded 1-50 with user-specified prefix and suffix strings. IMO custom format strings for pre- or suffixing are not seq's job. The OP wanted a little shell solution to create 50 directories with a fixed prefix and suffix, so what about this? seq -w 50 | sed 's/^/prefix/; s/$/suffix/' | xargs mkdir Have a ncie day, Berny
bug#12482: Feature Request: support for int, octal, and hex types in seq --format
retitle 12482 RFE: seq: add support for int, octal, hex formats in --format thanks Voelker, Bernhard wrote: Craig Sanders wrote: seq only supports floating point types like f and g in the --format string. Other types, including i,d,o,u,x,X would also be useful. e.g. seq --format 'prefix%02isuffix' 1 50 to print zero-padded 1-50 with user-specified prefix and suffix strings. IMO custom format strings for pre- or suffixing are not seq's job. I agreed, initially. The texinfo documentation gives examples of how to convert seq output to hexadecimal (%x) using printf: If you want hexadecimal integer output, you can use `printf' to perform the conversion: $ printf '%x\n' `seq 1048575 1024 1050623` f 1003ff 1007ff For very long lists of numbers, use xargs to avoid system limitations on the length of an argument list: $ seq 100 | xargs printf '%x\n' | tail -n 3 f423e f423f f4240 To generate octal output, use the printf `%o' format instead of `%x'. The OP wanted a little shell solution to create 50 directories with a fixed prefix and suffix, so what about this? seq -w 50 | sed 's/^/prefix/; s/$/suffix/' | xargs mkdir Hmm... The first time I ran an example like the above, I used -w without realizing that there was no need, since the printf format would handle the fixed width part. (the disadvantage with this approach is that you have to pre-compute the width and use that number in the printf format, whereas in Bernie's example, that's done automatically by seq -w. This suggests that seq's --equal-width (-w) option *would* be handy in conjunction with the requested integer format directives. Then, we'd get the benefit of -w along with the more direct use of a seq format string. ) $ seq -w 12 | xargs printf 'a-%02x-b\n' a-01-b a-02-b a-03-b a-04-b a-05-b a-06-b a-07-b a-printf: 08: value not completely converted 00-b a-printf: 09: value not completely converted 00-b a-0a-b a-0b-b a-0c-b [Exit 123] That looks like a bug, but printf is actually required to reject those two input strings. A leading 0 means octal. This does what you want: $ seq 12 | xargs printf 'a-%02x-b\n' a-01-b a-02-b a-03-b a-04-b a-05-b a-06-b a-07-b a-08-b a-09-b a-0a-b a-0b-b a-0c-b
bug#12482: Feature Request: support for int, octal, and hex types in seq --format
On Fri, Sep 21, 2012 at 10:19:13AM +0200, Jim Meyering wrote: Voelker, Bernhard wrote: Craig Sanders wrote: seq only supports floating point types like f and g in the --format string. Other types, including i,d,o,u,x,X would also be useful. e.g. seq --format 'prefix%02isuffix' 1 50 to print zero-padded 1-50 with user-specified prefix and suffix strings. IMO custom format strings for pre- or suffixing are not seq's job. the printf formats I suggested for seq are not specifically about prefixing or suffixing, they were just part of an example.. what i requested was non-floating point formats (the suffix and prefix strings are just a side-benefit of printf) - decimal, octal, and hex integer printf formats d,o,x, etc. if it supports floating-point, why not fixed or int? in fact, why floating-point at all? i can think of hundreds of uses in a shell script for printf-formatted ints from seq (and some for hex and even a few for octal), but not a single one for floating point. i'd use perl or python or something else if i wanted to do floating-point calculations (perl has a nice Math::BigFloat module and python, of course, has numpy and scipy). I agreed, initially. The texinfo documentation gives examples of how to convert seq output to hexadecimal (%x) using printf: yes, i know there are numerous ways to post-process seq's output. I even included a few in my answer to the stackexchange question i linked to. if there's some reason why floating point is possible but the integer formats are not then fair enoughbut it doesn't make sense to me to arbitrarily declare that floating-point printf support is OK but not integer. the examples using printf and xargs and so on are both obvious and missing the point. this bug report is not about them. it's about seq's incomplete support for printf. (the disadvantage with this approach is that you have to pre-compute the width and use that number in the printf format, whereas in Bernie's example, that's done automatically by seq -w. This suggests that seq's --equal-width (-w) option *would* be handy in conjunction with the requested integer format directives. Then, we'd get the benefit of -w along with the more direct use of a seq format string. ) yes! That looks like a bug, but printf is actually required to reject those two input strings. A leading 0 means octal. yeah, ran into that myself and thought WTF until i realised 'oh yeah. octal'. $ seq 12 | xargs printf 'a-%02x-b\n' yep, but i already knew that. i'm not asking for help to solve a problem. I'm submitting a wishlist level bug report for a feature enhancement to support more of printf's formatting capabilities in seq. craig -- craig sanders c...@taz.net.au
bug#12482: Feature Request: support for int, octal, and hex types in seq --format
Package: Coreutils Severity: wishlist seq only supports floating point types like f and g in the --format string. Other types, including i,d,o,u,x,X would also be useful. e.g. seq --format 'prefix%02isuffix' 1 50 to print zero-padded 1-50 with user-specified prefix and suffix strings. see http://unix.stackexchange.com/questions/48750/creating-numerous-directories-using-mkdir/48758#48758 for a real-world usage example. Thanks, craig -- craig sanders c...@taz.net.au
