Re: A fix for the F3 /var/log bug...

[Oswald Buddenhagen <ossi kde org>]

On Thu, May 29, 2003 at 02:44:59PM -0400, Alfie Costa (backup address) wrote:
> On 29 May 2003, at 0:09, Pavel Roskin <proski gnu org> wrote:
> > I believe double hash used in the patch is non-portable.
> 
> I only use Linux, so all I know for sure is that double hash works on Debian, 
> (ash, dash, bash, etc.), and judging by the 'ash/dash' man page, '##' (as 
> adopted from the Korn shell), now seems to be POSIX compliant...
> 
>                                                               The current ver-
>      sion of sh is in the process of being changed to conform with the POSIX
>      1003.2 and 1003.2a specifications for the shell.  [...]

>      We expect POSIX conformance by the time 4.4 BSD is released.
>
according to the unix history graph
(http://www.levenez.com/unix/history.html) this sentence must be at
least ten years old. ergo i would not bet on the accuracy of the rest of
the paragraph or other standards-related claims in this page.

> Could some kind SunOS or HP-UX user please test this code?
> 
> 	x=QuousqueTandemAbutere
> 	echo ${x##Quousque}
> 
/bin/sh on solaris 8: bad substitution
bye bye ...

On Thu, May 29, 2003 at 04:00:56PM -0400, Alfie Costa (backup address) wrote:
> On Thu, 29 May 2003 11:31, Oswald Buddenhagen wrote:
> > yep. it's [ double hashes ] a bash-ism (or a ksh-ism, fwiw). 
> It came from from Korn, but it's POSIX shell syntax now.
> 
the point is, that it does not matter whether it is posix-compliant ...
there are simply shells in active use that are non-posix.

> > other than that, i pretty much dislike this directory-based
> > special-casing. i think my suggestion with "file -z" (or equivalent)
> > is much cleaner. 
> [...]

> A 'file -z' clause wouldn't be locationally challenged, but it'd be slower.  
>
we are talking about viewing files here ... a .2 sec delay is not
exactly a catastrophe.

> In the meantime, for those who prefer the 'file -z' way, attached is
> the same patch, changed so it does it the 'file -z | grep' way.
>
this solution is sort of ... stupid ... :]

as mc does not automatically call file -z (or uncompresses the file
itself), i created the wrapper /usr/local/bin/file:

----------------------------
#! /bin/sh
/usr/bin/file -z "$@"
echo "Warning: -z switch implicitly used"
----------------------------

in mc.ext i have these:

--------------------------------
[here comes the .me & .ms stuff]

# Manual page - compressed
type/^(ASCII )?troff.*gzip compressed
        Open=gzip -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
        View=%view{ascii,nroff} gzip -dc %f | nroff  -Tlatin1 -mandoc

type/^(ASCII )?troff.*bzip compressed
        Open=bzip -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
        View=%view{ascii,nroff} bzip -dc %f | nroff  -Tlatin1 -mandoc

type/^(ASCII )?troff.*bzip2 compressed
        Open=bzip2 -dc %f | nroff  -Tlatin1 -mandoc | sensible-pager
        View=%view{ascii,nroff} bzip2 -dc %f | nroff  -Tlatin1 -mandoc

# Manual page
type/^(ASCII )?troff
        Open=nroff  -Tlatin1 -mandoc %f | sensible-pager
        View=%view{ascii,nroff} nroff  -Tlatin1 -mandoc %f

[... and here comes the video and image stuff. at least on my box]
--------------

the type/ query prolly does not even cost anything, as the info-page
pattern already calls file and i suppose mc caches the result.
of course file -z is slower than pure file, but we are talking about
uncompressing a few (hundred) bytes ...

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.