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. In short: * POSIX shell is more portable, obviously (even though it is not required here). * The language is simpler. * Faster. * 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 maybe other). -- Pierre Neidhardt Trap full -- please empty.