[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: pdfmerge

Matthew Palmer wrote:

On Wed, Mar 03, 2004 at 01:23:39PM +0800, Didier Casse wrote:
Well you can possibly argue that it's inefficient. You can list so many
packages in Debian that we can find a one-liner turnaround. I believe you
can list many, so why don't you start taking them off.

Find 'em, give us one line equivalents, and I, personally, will be happy to
encourage the maintainers to merge their scripts into appropriate packages.

pretty much everything in coreutils could be done with a perl one liner. And in fact, they have - the perl power shell (psh) does them all.

Perl one liners can replace most common commands - not suprising since perl started off filling in the gaps and making life easier.

I'd like this trend to continue. As a sysadmin, using Solaris is about as much fun as being beaten, thanks to the lack of unecessary and frivolous scripts like this one. I always prefer working on the Debian servers.

Everytime I have to type "find / | grep -i 'file-name'" on Solaris I find myself longing for the sane distribution. Let's do whatever we need to make user's lives easier.

And before you remind me that Solaris has 'locate', I'll remind you that it doesn't because our sadistic super-admin didn't install it seeing as how it could be done with a one-liner.

Oh yeah... find can be done with a perl one-liner. On some distros, it is a perl script. grep is a one-liner. And if we all went to Perl, we could have perl regular expressions instead of the horrible POSIX ones.

I wouldn't bet on it if I were you. This script is in the ATrpms
repository <http://atrpms.physik.fu-berlin.de/> and many people from
RH/Fedora world are already doing an

apt-get install pdfmerge

for your information.

And may the world tremble at your accomplishment.

If people are using it, we should include it.

Eh?  Where has someone said "we do not want pdfmerge in Debian"?  There have
been queries about your implementation, and about your intentions to produce
a separate package for it, and a (quite valid) suggestion to submit it to GS

But then we end up with the redhat madness where it's hard to find a particular program because it has been lumped in with some related package that doesn't share the name.

Reply to: