[pacman-dev] [PATCH 1/2] contrib: adding pacsize
ambrevar at gmail.com
Wed Mar 5 11:40:23 EST 2014
On 14-03-05 10:50:30, Dave Reisner wrote:
> On Wed, Mar 05, 2014 at 04:00:16PM +0100, Pierre Neidhardt wrote:
> > Printing package size is useful for maintenance. Indeed, the first entry on the
> > wiki is focused on this topic:
> > https://wiki.archlinux.org/index.php/Pacman_Tips#Maintenance
> > None of the proposed solutions will allow you to:
> > - select packages;
> > - work on the output of other commands yielding a list of packages;
> > - change the sorting;
> > - be locale independent;
> > - print a grand total;
> > - be fast (most solutions are wasting a lot of time -- only expac is faster);
> > - not rely on any third-party tool.
> > Pacsize is a POSIX shell script that is generic enough to enclose all these
> > features (and more).
> I truly do not understand why you've chosen to write this in POSIX shell
> when every other shell script in the pacman repo is written in bash.
Well, since some scripts are written in perl, I guess we are free to chose
the language as long as it does not add other dependencies.
The true reason I chose POSIX shell over bash is that I do not endorse bash. So
what I cannot do in POSIX shell (mainly when recursive file processing and
structures are involved), then I call Perl.
* POSIX shell is more portable, obviously (even though it is not required here).
* The language is simpler.
* The code is often equivalent, both in size and expressivity (not considering
the structures here). So why do sth unportable if you can do it the standard way
without losing anything?
* Ugly is arguable, but I wouldn't say bash is beautiful either. But I do not
want to start a flame war, so I will stop here.
Here POSIX shell shows no limitation for the task. I do not think the code could
not be shorter in bash.
> A lot of the constructs in your script are made considerably uglier and more
> fragile than needed because of this decision.
I may have written some fragile code somewhere. Thinking about something in particular?
> > Adding a 'pacsize' script eliminates the unneeded abundance of workarounds for
> > this simple matter.
> Ok, I'll bite. Why aren't we working on merging expac (or something like
> expac)? Adding yet another tool tool which relies on parsing unstable
> output from pacman seems like a step in the wrong direction.
Yes! I totally agree. This will render this script obsolete (as well as pacsysclean and
Trap full -- please empty.
More information about the pacman-dev