[9fans] netpbm

[9fans] netpbm

[cej]

for those who might be interested, an APE  port of netpbm is at:
http://www.gli.cas.cz/home/cejchan/neXt/imaging/netpbm-10.11.tbz <http://www.gli.cas.cz/home/cejchan/neXt/imaging/netpbm-10.11.tbz> 
 
(few things: fiasco, bmp, and mpeg not ported yet)
enjoy!
++pac.
 
 

[9fans] netpbm

[tapique]

those interested, grablatest version of netpbm at:

http://www.gli.cas.cz/home/cejchan/neXt/imaging/netpbm-10.26.1.tbz

please, test it heavily as it is intended to be included in the next official
release...
thanks,

++pac.


--------------------------
Posílejte SMS přes internet zdarma a bez reklamy. Pouze s TISCALI.
Více na http://www.tiscali.cz

Re: [9fans] netpbm

[arisawa]

Hello,

How to unpack netpbm-10.26.1.tbz ?

term% gunzip netpbm-10.26.1.tbz
gunzip: netpbm-10.26.1.tbz is not a gzip deflate file
term%

Kenji Arisawa
E-mail: arisawa@ar.aichi-u.ac.jp

Re: [9fans] netpbm

[Lucio De Re]

> term% gunzip netpbm-10.26.1.tbz
> gunzip: netpbm-10.26.1.tbz is not a gzip deflate file

"bunzip2" rather than "gunzip".

Is it not possible to use a single utility that recognises the nature
of the archive?  Enhanced Unix "tar" utilities all seem to be able to
do it.

I haven't explored how it is implemented, but I recall vaguely a
discussion in one of the NetBSD mailing lists about trivially adding
bunzipping to TAR a long time ago.

++L


++L

Re: [9fans] netpbm

[geoff]

I've written a new (faster) tar and at Russ's suggestion have made it
recognise the compressed tar archives.  I think it's up to Russ
whether or not it becomes the sstandard tar.

Re: [9fans] netpbm

[Lucio De Re]

> I've written a new (faster) tar and at Russ's suggestion have made it
> recognise the compressed tar archives.  I think it's up to Russ
> whether or not it becomes the sstandard tar.

That has _my_ vote, for all it may be worth.  Maybe I ought to look at
integrating the various uncompressors or at least providing a single
front-end for them myself.  But these things just disappear into a
time warp as my time is too fragmented (bad habits) for me to conclude
anything of any magnitude :-(

++L

Re: [9fans] netpbm

[Lucio De Re]

> I've written a new (faster) tar and at Russ's suggestion have made it
> recognise the compressed tar archives.  I think it's up to Russ
> whether or not it becomes the sstandard tar.

I also note that APE has PAX in it, probably an ancient version.  I'm
no fan of PAX and I agree with Rob that APE is inconsistent with the
Plan 9 philosophy, but I don't think perpetuating obsolence is a great
option either, so updating ape/pax may be worth looking into.

++L

Re: [9fans] netpbm

[boyd, rounin]

> I've written a new (faster) tar and at Russ's suggestion have made it
> recognise the compressed tar archives.

i'm opposed. compress/uncompress programs should do that.

tar should tar.

or write a script that uses file etc and does the right thing.
--
MGRS 31U DQ 52572 12604

Re: [9fans] netpbm

[geoff]

Russ requested recognising compressed archives by name (e.g., *.tgz)
when extracting, and creating compressed archives under `rz'
key-letters, with the compressor determined by the archive name.  It
doesn't use a different key-letter (option) for each compression
scheme.  It's table-driven and just runs the appropriate compressor or
decompressor.  We've all got shell scripts to do this sort of thing,
but dealing with compressed archives is a common case and I don't see
much harm in having tar initiate one end of a pipeline internally
rather than requiring the user to do it externally.

My tar.c is 994 lines currently, a little bigger than
/sys/src/cmd/tar.c at 795 lines.  It looks like 102 lines are devoted
to dealing with compressed archives.

Re: [9fans] netpbm

[andrey mirtchovski]

> My tar.c is 994 lines currently, a little bigger than
> /sys/src/cmd/tar.c at 795 lines.  It looks like 102 lines are devoted
> to dealing with compressed archives.

how about the 128-character name limit which gnu tar has extensions for?

e.g. (original p9 tar):

plan9% touch `{perl -e 'print "A"x130'}
plan9% tar cv AA*
tar: name too long for tar header: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
plan9%

Re: [9fans] netpbm

[geoff]

My tar creates POSIX "ustar" archives by default, which can handle
names up to 255 bytes as long as they can be split at a `/' into two
strings, the first 155 or fewer bytes long and the second 100 or fewer
bytes long.  It also recognises "ustar" archives automatically when
reading archives, as does the standard tar.

Re: [9fans] netpbm

[geoff]

I should add that names are split only if necessary when writing
"ustar" archives, so "ustar" archives containing only names 100 or
fewer bytes long can be read with no problem by old tars.

Re: [9fans] netpbm

[Bruce Ellis]

Respect Doug.  Pipes are your friend. Or throw emacs into tar.
I'm sure that's not out of line with "don't use pipes".

brucee

On Fri, 4 Feb 2005 22:38:17 +0100, boyd, rounin <boyd@insultant.net> wrote:
> > I've written a new (faster) tar and at Russ's suggestion have made it
> > recognise the compressed tar archives.
>
> i'm opposed. compress/uncompress programs should do that.
>
> tar should tar.
>
> or write a script that uses file etc and does the right thing.

Re: [9fans] netpbm

[arisawa]

>Is it not possible to use a single utility that recognises the nature
>of the archive?  Enhanced Unix "tar" utilities all seem to be able to
>do it.
I have, but we should add more.

Kenji Arisawa

Re: [9fans] netpbm

[arisawa]

Mine is
#!/bin/rc -e
# unpack file ...
#   foo.gz   -> foo          in case of file.
#   foo.tar.gz   -> foo      in case of dir.
#   foo. -> DO NOTHING
#   foo  -> DO NOTHING
#
# coded by Kenar
#
fn usage {
	echo 'usage: unpack  file ...'
	exit usage
}

fn error {
	echo $*
	exit 'not found'
}

if(~ $#* 0) usage

while (! ~ $#* 0 ){
	x = $1
	if (test ! -e $x) error file $x not found
	f = 1
	while(~ $f 1){
	switch($x){
	case *.gz
		gunzip $x
		x=`{basename $x .gz}
	case *.tgz
		gunzip $x
		x=`{basename $x .tgz}^.tar
	case *.tar
		tar -xf $x
		echo rm $x
		x=`{basename $x .tar}
	case *.bz2
		bunzip2 $x
		x=`{basename $x .bz2}
	case *.tbz
		bunzip2 $x
		x=`{basename $x .tbz}^.tar
	case *.tbz2
		bunzip2 $x
		x=`{basename $x .tbz2}^.tar
	case *
		f=0
	}
	}
	shift
}

More decoding methods should be added.
And I rarely uses execept gzip.
Therefore not so much debugged.

Kenji Arisawa

Re: [9fans] netpbm

[Lucio De Re]

> More decoding methods should be added.
> And I rarely uses execept gzip.
> Therefore not so much debugged.

I'd think the plumber could be drawn into this?

	bunzip2 < abc.tar.bz2 | {cd somewhere && tar xv}

is my usual way to deal with this.

++L

Re: [9fans] netpbm

[arisawa]

> I'd think the plumber could be drawn into this?
>
> 	bunzip2 < abc.tar.bz2 | {cd somewhere && tar xv}
>
> is my usual way to deal with this.
>

good idea to plumb tar file. my preference is fs/tarfs.

Kenji Arisawa

Re: [9fans] netpbm

[Sam]

>> I'd think the plumber could be drawn into this?
>>
>> bunzip2 < abc.tar.bz2 | {cd somewhere && tar xv}
>>
>> is my usual way to deal with this.
>>
>
> good idea to plumb tar file. my preference is fs/tarfs.

In case no one has noticed, tarfs/tapefs is in man
sections 1 and 4, with the only difference being that
the section 1 variant documents zipfs.

Sam

Re: [9fans] netpbm

[andrey mirtchovski]

i liked this when i first saw it and still think it's relevant:

	http://cm.bell-labs.com/wiki/plan9/intro_to_tools_philosophy_for_*nix_users/index.html

whoever wrote it made a nice job explaining why it's pointless to hack
tar adding z (gzip/gunzip) and j (bzip2/bunzip2) options...

Re: [9fans] netpbm

[Lucio De Re]

> whoever wrote it made a nice job explaining why it's pointless to hack
> tar adding z (gzip/gunzip) and j (bzip2/bunzip2) options...

There's plenty of room for disagreement here:

	- The pipeline is not reserved for the shell's sole use.

		TAR can spawn a decompressor and read its output
		without user intervention.  The shell's contribution
		here would be the ease of change.  Casting it in TAR
		stone may (usefully ot otherwise) discourage
		enhancements (it didn't when Bzip2 was introduced).

	- Anything more complex than a pipe isn't suitable for purely command line use.

		TAR can inspect the archive and determine its format
		(it's a published header), selecting the most
		appropriate tool for decompression.  My suggestion was
		to move the identification into the decompressors, but
		in this case we're merely extending TAR's existing
		capabilities.  Whether the filename suffix is a
		suitable discriminator is for some other jury.  PAX,
		unless I'm mistaken, will even choose TAR or CPIO as
		the archiver, which is commendable if one is looking
		for simplification in a different realm.

	- One can push the principle to breaking point.

		"One task, one program".  By that token, there ought
		to be a TAR and an UNTAR as I don't see them as
		equivalent.  In fact fa/tarfs (or whatever) is a case
		in point and I have no reservations in this regard.
		But one can shift the "task" definition, too.  There
		are hundreds of archive formats, all in some use and
		having to be familiar with each is painful.  A utility
		that subsumes at least the extraction process into a
		single operation is not to be sneered at.  Of course,
		one has to be realistic, too.

In my opinion, the "one task, one program" principle is very sensible
for modelling and should only be abandoned when the components have
been so carefully tested that it is possible to combine them together
without major unpredictable problems being created.  Programming
skills have a great influence here: I would trust Geoff's
multi-purpose TAR more than I would trust my own simple attempt at a
TAR implementation.

++L

Re: [9fans] netpbm

[C H Forsyth]

>>Enhanced Unix "tar" utilities all seem to be able to do it.

i dare say it can.
cd /usr/src/contrib/tar; wc -l lib/*.c src/*.c
	... far too many files
   24449 total

and that's an old version. it has got `remote tape access',
though.  i'd forgotten about that. there's probably a command
language interpreter in there somewhere.

plan 9's pax is only 9000 lines, and is a little behind the times:
cd /usr/src/bin/pax; wc -l *.c
	...
    13455 total

does anyone still use cpio or pax?  apparently
it's like that OSI stuff that never quite dies,
however many stakes have been banged through its heart.

Re: [9fans] netpbm

[Tiit Lankots]

> however many stakes have been banged through its heart.

s/its heart/its black heart/

Re: [9fans] netpbm

[Derek Fawcus]

On Fri, Feb 04, 2005 at 09:31:30AM +0000, C H Forsyth wrote:
> does anyone still use cpio or pax?  apparently

Linux distributions...  At heart the archive inside a .rpm
file is in a cpio varient,  there is even a rpm2cpio filter.

Re: [9fans] netpbm

[Ronald G. Minnich]

On Fri, 4 Feb 2005, Derek Fawcus wrote:

> Linux distributions...  At heart the archive inside a .rpm
> file is in a cpio varient,  there is even a rpm2cpio filter.

linux initrd are now cpio archives.

ron

Re: [9fans] netpbm

[Charles Forsyth]

>> Linux distributions...  At heart the archive inside a .rpm
>> file is in a cpio varient,  there is even a rpm2cpio filter.

>linux initrd are now cpio archives.

i see.  clearly stakes didn't work on that one!

Re: [9fans] netpbm

[boyd, rounin]

> does anyone still use cpio or pax?  apparently

cpio should be dead by now -- horrible thing.
--
MGRS 31U DQ 52572 12604

Re: [9fans] netpbm

[Ronald G. Minnich]

On Fri, 4 Feb 2005, boyd, rounin wrote:

> cpio should be dead by now -- horrible thing.

it will live forever. No file format ever dies. Just look at SREC!

ron

Re: [9fans] netpbm

[boyd, rounin]

> it will live forever. No file format ever dies. Just look at SREC!

yuk, if you mean S-records.  gawd, i remember burning EPROMs with those.
--
MGRS 31U DQ 52572 12604

Re: [9fans] netpbm

[arisawa]

Hello pac,

Thanks for your elaboration

term% tar -xf netpbm-10.26.1.tar
tar: mkdir /usr/pac failed: permission denied
tar: mkdir /usr/pac/wrk failed: '/usr/pac/wrk' does not exist
tar: mkdir /usr/pac/wrk/netpbm-10.26.1 failed: '/usr/pac/wrk/netpbm-10.26.1' does not
...

Therefore I used fs/tarfs + cpdir

Following your instruction in README.plan9

term% cp pm_config.9.h pm_config.h
term% cd lib
term% mk
libnetpbm.a doesn't exist: assuming it will be an archive
pcc -c -I .. -I util -B -D_PLAN9 -D_POSIX_SOURCE -D_SUSV2_SOURCE -I ../ -D_BSD_EXTENSION bitio.c
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] not a function
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] syntax error, last name: uint32n
pcc: cpp: 8c 2219: error
mk: pcc -c -I ...  : exit status=rc 2216: pcc 2218: cpp: 8c 2219: error
term% ape/psh
# pwd
/usr/local/src/pac/netpbm-10.26.1/lib
# mk
libnetpbm.a doesn't exist: assuming it will be an archive
pcc -c -I .. -I util -B -D_PLAN9 -D_POSIX_SOURCE -D_SUSV2_SOURCE -I ../ -D_BSD_EXTENSION bitio.c
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] not a function
/usr/local/src/pac/netpbm-10.26.1/lib/../pm_config.h:169[stdin:166] syntax error, last name: uint32n
pcc: cpp: 8c 2364: error
mk: pcc -c -I ...  : exit status=rc 2361: pcc 2363: cpp: 8c 2364: error
#

It seems your help is needed.
Thanks in advance.

Kenji Arisawa

Re: [9fans] netpbm

[arisawa]

> Hello pac,
>

Sorry, that is thrown into 9fans. just my fault.

Kenji Arisawa

[9fans] netpbm

[tapique]

hi, friends!

thanks for care, i'm back again after a couple of  days of working hard
in the lab (having no assistant, sigh). now netpbm should compile fine,
grab the fresh version:
http://www.gli.cas.cz/home/cejchan/neXt/imaging/netpbm-10.26.1.tbz
or with precompiled bins
http://www.gli.cas.cz/home/cejchan/neXt/imaging/netpbm-10.26.1.+bin.tbz

now with jpeg2000 support!

sorry for having released a dead beast before, enjoy,

++pac.


--------------------------
Posílejte SMS přes internet zdarma a bez reklamy. Pouze s TISCALI.
Více na http://www.tiscali.cz

[9fans] netpbm

[tapique]

archive moved from www back to anonymous ftp:

ftp://ftp.gli.cas.cz/cej/neXt/
(find netpbm under ./imaging)

pls report if access denied to <tapique *AT* tiscali.cz>

thanks,
++pac.


--------------------------
Posílejte SMS přes internet zdarma a bez reklamy. Pouze s TISCALI.
Více na http://www.tiscali.cz