flexfax: Re: Solution: /usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.../../../sparc-sun-solaris2.7/include/assert.h

[James Lee <jameswlee@lineone.net>]

Tuesday November 23 14:27:43 GMT 1999

Update to my previous message, 22/11/1999.
Re HylaFAX Problem:
make: *** No rule to make target
`/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.../../../sparc-sun-solaris2.7/include/assert.h',
needed by `faxcover.o'.  Stop.


Clarification
=============

In response to my statement:
> ``ABCD/../'' will disappear.
Nico Kadel-Garcia writes:
> Except that gcc -M does in fact do *EXACTLY* this for the file "assert.h".

No, not *EXACTLY* at all, allow me to clarify.
With my previous script:
``XXXX/ABCD/../YYYY'' became ``XXXX/YYYY''
and
``ABCD/../'' ALONE will DISAPPEAR

Great if line contains:
``/usr/local/lib/gcc-lib/sparc-sun-solaris2.7/2.95.1/../../../../sparc-sun-solaris2.7/include/assert.h''
*EXACTLY* as in the HylaFAX gcc -M problem.  Useless if line contains the word:
``2.95.1/../''
as the word disappears.


So, I can do better
===================

The script keeps growing, but it's hardly `bloatware' in the M*crS*ft sense.
``ABCD/../'' is now safe, (as long as ABCD is not a link, see below).

old line 252 and 253 in ``hylafax-v4.0pl2/port/mkdepend.in'':
	-e :loop -e 's:[^\./][^\./]*/\.\./::g' -e tloop \
	-e 's:\([/ ]\)\./:\1:g' \
new:
	-e s:///*:/:g -e 's:\(.*\): \1:' -e 's: \([^/^ ]\): ./\1:g' \
	-e :a -e 's:/\./:/:' -e 's:/\.\./://:' -e ta \
	-e :b -e 's:/[^/^ ][^/^ ]*//:/:' -e tb \
	-e :c -e s://:/../: -e tc \
	-e 's: \./\([^ ]\): \1:g' -e 's:^ \(.*\):\1:' \


Links
=====

Well spotted, this is nothing to do with the failure of my script, ANY
simple textual process will fail, eg: 

$ ls -d /cdrom
/cdrom
$ ls -d /usr/bin/../../cdrom
/usr/bin/../../cdrom
$ ls -d /usr/man/../../cdrom
/usr/man/../../cdrom: No such file or directory
$ ls -d `echo /usr/man/../../cdrom | sed.script`
/cdrom
$ ls -d /usr/man/../../../cdrom
/usr/man/../../../cdrom
$ ls -l /usr/man
lrwxrwxrwx   1 root     root          16 Jan 17 14:19 /usr/man -> ./share/man

ls knows, the sed script can't.  Interestingly for us it's the correct
path which is non-intuitive.  Without knowing that ``/usr/man'' was a
link, ``/usr/man/../../cdrom'' looks good.  Yes the sed name
simplification can be broken, but only if you try.  You would have to
be relying on a directory being a link, eg:

$ ls -l /usr/local
lrwxrwxr-x   1 root     other         18 Jan 21 16:39 /usr/local -> /export/home/local
$ gcc -M -I /usr/local/../../home/james file.c
file.o: file.c /usr/local/../../home/james/file.h
$ ls /usr/local/../../home/james/file.h
/usr/local/../../home/james/file.h
$ ls `echo /usr/local/../../home/james/file.h | sed.script`
/home/james/file.h: No such file or directory

I believe links should be used transparently, this example does not do
this so deserves to fail.


Perhaps the name simplification should just be ignored.
Written by machine for machine; why does it matter?



James Lee
jameswlee@lineone.net