A fix for the F3 /var/log bug...
Oswald Buddenhagen
ossi at kde.org
Thu May 29 21:26:03 UTC 2003
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 at 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.
More information about the mc-devel
mailing list