Re: Progress bar again

[Alfred M. Szmidt]

   Thanks about your comments. I did not know about that dd feature
   and it looks very interesting. I think that sending the SIGUSR1
   signal to a process is a better way to collect progress information
   than a fixed progress bar on each software. I could write something
   similar feature to cp and mv. I could even write a completely new
   program fetching this information from different programs in
   different formats and printing a progress bar to end user.

   For example:
           $ pb cp file file2
           `file1'->`file2' 20% [20/100 MiB]

   and user could customize the progress bar by editing some configuration
   file, ~/.pb.conf for example.

   What would you think about this idea?

I like it to some extent.  It would allow for programs to implement
progress bars quite easily, without getting all kind of weird code for
printing them.  But instead of a config file, could you please use an
option?  There is no need for a configuration file for such a small
program, you could do something like what date does. For example,

$ pb --set="%s -> %d %p%% [%a/%t]" cp foo bar
foo -> bar 33% [512/1024]

Where,

 %% - %
 %a - amount copied at this time instant.
 %d - destination/directory.
 %p - percentage.
 %s - source.
 %t - total amount to be copied.

And if the user doesn't like the default progress bar string, then
they can always use an alias.  Obviously, there would be more
directives then just the above, for example you could have directives
for the speed of the transfer (10K/sec), show things in human-readable
form (10G), etc.  And more useful options, like specifing the update
interval, etc.


Configuration files tend to be abused to much these days, resulting in
a horrible mess in ${HOME} where you have a dozen or more 10 line
files, that tend to have their default values stored there.  The only
time you really need a configuration file is when:

 - you want to let a user define marcos of some kind--emacs and gdb
   are good example here,
 - you have an daemon that gets started on boot, and even then in most
   cases you don't need a configuration file, or
 - you have a GUI program.

Another mess with all these configuration files is that they always
differ in syntax; which just causes pain for users and for developers
that have to implement or debug the parser for the configuration file. 

In short, just using sane default values, and good command line
options will work far better then any obscure configuration file.

I think I'm done brain storming for today, cheers!