Re: feature request: {#} with leading zeroes

[Shao Zhang]

In production, we only really have 2 types of sequential formatting.
No leading zeros:

8,9,10,11

and fixed number of digits:

008,009,010,011

'Three digits or more' is not really a case I've seen in the wild.
Just my 2 cents having to work with production image sequences on a
daily basis.  I typically use parallel to convert images out of order
in which case this functionality isn't necessary.

We do have internal tools that will process sequentially like this:

loop 1-1000 -cpus 8 'convert this.%d.tif that.%6d.jpg'

Which isn't guaranteed to be 100% sequential when cpus > 1 but its
never going to be horribly out of order.

I'm not sure if the functionality is necessary unless there's
something that absolutely needs to be done in order or roughly in
order.

You can always break out your data by dirs and run parallel against
the ones you want done first.

On Thu, Mar 15, 2012 at 1:36 PM, Ole Tange <tange@gnu.org> wrote:
> On Thu, Mar 15, 2012 at 2:50 PM, Thomas Sattler
> <sattler@med.uni-frankfurt.de> wrote:
>> There is an example for {#} in the manpage. Its description says,
>> it might be "useful for making input PNG's for ffmpeg":
>>
>> |
>> | find . -type f | sort | parallel convert {} {#}.png
>> |
>>
>> I'd guess that it wouldn't work with ffmpeg, as the images would
>> be sorted like this:
>>
>>  10.png 11.png 12.png [...] 18.png 19.png 1.png [...]
>>
>> Wouldn't it be usefull to have sequence numbers with leading
>> zeroes here?
>
> Show me more examples where it would be useful. The ffmpeg could be fixed 
> with:
>
> ls | sort -n | parallel -j 1 -X ffmpeg ... {}
>
> If there are better use cases I might consider something like:
>
>  {0#} = {#} = one digit or more
>  {000#} = three digits or more
>
> /Ole
>