Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #264430 > unrolled thread

Image handling in mutt

Back to article view | Back to linux.debian.user

Contents

  Image handling in mutt Paul M Foster <paulf@quillandmouse.com> - 2023-12-08 18:00 +0100
    Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-08 18:10 +0100
      Re: Image handling in mutt Paul M Foster <paulf@quillandmouse.com> - 2023-12-08 22:50 +0100
        Re: Image handling in mutt David <bouncingcats@gmail.com> - 2023-12-08 23:00 +0100
          Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-08 23:10 +0100
            Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-08 23:40 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-08 23:50 +0100
                Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:00 +0100
                  Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:10 +0100
                    Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:20 +0100
                      Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:30 +0100
                Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:00 +0100
              Re: Image handling in mutt John Hasler <john@sugarbit.com> - 2023-12-09 00:00 +0100
                Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-09 00:00 +0100
                  Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-09 00:30 +0100
            Re: Image handling in mutt Eric S Fraga <e.fraga@ucl.ac.uk> - 2023-12-09 09:50 +0100
              Re: Image handling in mutt Curt <curty@free.fr> - 2023-12-10 17:20 +0100
                Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-10 17:30 +0100
                  Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-10 19:40 +0100
                    Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-10 19:50 +0100
                      Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:20 +0100
                      Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-11 02:30 +0100
                        Re: Image handling in mutt debian-user@howorth.org.uk - 2023-12-11 16:30 +0100
                          Re: Image handling in mutt songbird <songbird@anthive.com> - 2023-12-11 21:20 +0100
            Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 12:40 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 13:30 +0100
          Re: Image handling in mutt "Loris Bennett" <loris.bennett@fu-berlin.de> - 2023-12-11 14:10 +0100
        Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-10 21:10 +0100
          Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-10 22:00 +0100
            Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 13:20 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 13:40 +0100
                Re: Image handling in mutt Arno Lehmann <al@its-lehmann.de> - 2023-12-11 13:50 +0100
                  Re: Image handling in mutt Greg Wooledge <greg@wooledge.org> - 2023-12-11 14:20 +0100
                    Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:10 +0100
                      Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 15:40 +0100
                        Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 16:20 +0100
                    Re: Image handling in mutt "Jeremy Nicoll" <jn.ml.dbi.73@letterboxes.org> - 2023-12-11 19:00 +0100
                      Re: Image handling in mutt jeremy ardley <jeremy.ardley@gmail.com> - 2023-12-11 23:10 +0100
                        On file systems [was: Image handling in mutt] <tomas@tuxteam.de> - 2023-12-12 06:40 +0100
                          Re: On file systems "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-12 11:50 +0100
                Re: Image handling in mutt Eric S Fraga <e.fraga@ucl.ac.uk> - 2023-12-11 13:50 +0100
                Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:00 +0100
                  Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 15:20 +0100
                    Re: Image handling in mutt Vincent Lefevre <vincent@vinc17.net> - 2023-12-11 15:40 +0100
                      Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 15:50 +0100
                      Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 15:50 +0100
            Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 16:00 +0100
              Re: Image handling in mutt Pocket <pocket@columbus.rr.com> - 2023-12-11 16:10 +0100
                Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 17:10 +0100
              Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 16:10 +0100
                Re: Image handling in mutt Stefan Monnier <monnier@iro.umontreal.ca> - 2023-12-11 16:20 +0100
                  Re: Image handling in mutt <tomas@tuxteam.de> - 2023-12-11 16:30 +0100
    Re: Image handling in mutt Zenaan Harkness <zenaan@gmail.com> - 2023-12-11 00:10 +0100
      Re: Image handling in mutt Zenaan Harkness <zenaan@gmail.com> - 2023-12-11 01:20 +0100
      Re: Image handling in mutt David Wright <deblis@lionunicorn.co.uk> - 2023-12-11 16:30 +0100

Page 1 of 3  [1] 2 3  Next page →

#264430 — Image handling in mutt

Folks:

I'm on Debian bookworm, using neomutt for email. Where there is an image to
view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
the "display" alternative to feh with update-alternatives. Still, mutt is
calling an imagemagick program to display jpgs.

First, if alternatives doesn't point to the imagemagick program, and the
mailcap file doesn't point to it, and there's nothing in the neomutt config
pointing to the imagemagick program, then where the heck is it getting that
as the program to use to display images?

Second, how do I fix this so that mutt uses feh to display images?

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [next] | [standalone]

#264434

On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> 
> I'm on Debian bookworm, using neomutt for email. Where there is an image to
> view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
> set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
                                  ↑↑↑ try jpeg

> the "display" alternative to feh with update-alternatives. Still, mutt is
> calling an imagemagick program to display jpgs.
> 
> First, if alternatives doesn't point to the imagemagick program, and the
> mailcap file doesn't point to it, and there's nothing in the neomutt config
> pointing to the imagemagick program, then where the heck is it getting that
> as the program to use to display images?
> 
> Second, how do I fix this so that mutt uses feh to display images?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#264447

On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:

> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
> > 
> > I'm on Debian bookworm, using neomutt for email. Where there is an image to
> > view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> > the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
> > set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
>                                   ↑↑↑ try jpeg
> 
> > the "display" alternative to feh with update-alternatives. Still, mutt is
> > calling an imagemagick program to display jpgs.
> > 
> > First, if alternatives doesn't point to the imagemagick program, and the
> > mailcap file doesn't point to it, and there's nothing in the neomutt config
> > pointing to the imagemagick program, then where the heck is it getting that
> > as the program to use to display images?
> > 
> > Second, how do I fix this so that mutt uses feh to display images?

I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
the files I was looking at had a "jpg" extension.

But thanks for the tip.

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

[toc] | [prev] | [next] | [standalone]

#264449

On Fri, 8 Dec 2023 at 21:45, Paul M Foster <paulf@quillandmouse.com> wrote:
> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
> > On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:

> > > I'm on Debian bookworm, using neomutt for email. Where there is an image to
> > > view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
> > > the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
> > > set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
> >                                   ↑↑↑ try jpeg
> >
> > > the "display" alternative to feh with update-alternatives. Still, mutt is
> > > calling an imagemagick program to display jpgs.
> > >
> > > First, if alternatives doesn't point to the imagemagick program, and the
> > > mailcap file doesn't point to it, and there's nothing in the neomutt config
> > > pointing to the imagemagick program, then where the heck is it getting that
> > > as the program to use to display images?
> > >
> > > Second, how do I fix this so that mutt uses feh to display images?
>
> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
> the files I was looking at had a "jpg" extension.

Hi, the filename extension is usually irrelevant on Linux, because
Linux tools typically
use the standard 'file' command to inspect the content of the
fileinstead of relying on
the filename to indicate content.

What is more likely important is that the keywords in the output of
'file <imagefile>'
command are correctly specified in your desired configuration.

[toc] | [prev] | [next] | [standalone]

#264450

On 12/8/23 16:53, David wrote:
> On Fri, 8 Dec 2023 at 21:45, Paul M Foster <paulf@quillandmouse.com> wrote:
>> On Fri, Dec 08, 2023 at 11:04:54AM -0600, David Wright wrote:
>>> On Fri 08 Dec 2023 at 11:56:12 (-0500), Paul M Foster wrote:
>>>> I'm on Debian bookworm, using neomutt for email. Where there is an image to
>>>> view, viewing it in neomutt calls up one of the ImageMagick programs. I've set
>>>> the mailcap_path variable in my neomutt config to point to ~/.mailcap, and
>>>> set an entry in there for image/jpg to point to /usr/bin/feh. I've even set
>>>                                    ↑↑↑ try jpeg
>>>
>>>> the "display" alternative to feh with update-alternatives. Still, mutt is
>>>> calling an imagemagick program to display jpgs.
>>>>
>>>> First, if alternatives doesn't point to the imagemagick program, and the
>>>> mailcap file doesn't point to it, and there's nothing in the neomutt config
>>>> pointing to the imagemagick program, then where the heck is it getting that
>>>> as the program to use to display images?
>>>>
>>>> Second, how do I fix this so that mutt uses feh to display images?
>> I can't believe that worked. The /etc/mailcap has both (jpg and jpeg), and
>> the files I was looking at had a "jpg" extension.
> Hi, the filename extension is usually irrelevant on Linux, because
> Linux tools typically
> use the standard 'file' command to inspect the content of the
> fileinstead of relying on
> the filename to indicate content.


In Unix and Linux there isn't a file extension, that is a microsoft 
invention.

Unix and Linux filespecs are just a bunch of characters

https://www.linfo.org/file_name.html

The period in a linux filespec is just a period and nothing more


>
> What is more likely important is that the keywords in the output of
> 'file <imagefile>'
> command are correctly specified in your desired configuration.
>
-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264451

On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

cc(1) and make(1) would like to have a talk with you.

[toc] | [prev] | [next] | [standalone]

#264452

On 12/8/23 17:31, Greg Wooledge wrote:
> On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
>> In Unix and Linux there isn't a file extension, that is a microsoft
>> invention.
> cc(1) and make(1) would like to have a talk with you.
>
Linux/Unix filenaming specs would like to inform you.

file specs/naming i Unix and Linux are 355 characters and nothing more.

I am surprised you don't know that


-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264455

On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote:
> 
> On 12/8/23 17:31, Greg Wooledge wrote:
> > On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
> > > In Unix and Linux there isn't a file extension, that is a microsoft
> > > invention.
> > cc(1) and make(1) would like to have a talk with you.
> > 
> Linux/Unix filenaming specs would like to inform you.
> 
> file specs/naming i Unix and Linux are 355 characters and nothing more.
> 
> I am surprised you don't know that

cc(1) looks at the file extension to decide what kind of content each
named argument file is expected to contain.  A .c file is expected to
contain C language source code; a .o file is expected to contain object
code; a .s file is expected to contain assembly language source code;
and so on.  It invokes the compiler, the assembler, and/or the linker
depending on what kinds of files it has been given.

make(1) lets you define a rule for converting an input file with extension
E1 to an output file with extension E2.  These rules will be applied in
the absence of specific overrides.  If you define a rule like ".xx.yy:"
then make will use this to turn any *.xx file into a matching *.yy file.
Then you can type, for example, "make frog.yy" and it will look for
frog.xx and frog.yy, compare their timestamps, and if needed, apply your
custom rule to generate the frog.yy file.

While I'm giving examples, there's also Apache, which decides what
Content-type header to generate for a given static file based on its
extension.  I would imagine other web servers do the same thing.

And hey, I'm using mutt to compose and send this email.  If I were to
attach a file to this message, mutt would look at its extension to
decide what MIME type to give it.

Your notion that "most Unix programs use file(1) output to decide a file's
content" is simply not universal.  I don't even think it's *common*,
especially given how inconsistent file's output is.  Most programs
that need to determine content types dynamically look at extensions.
Even on Unix.

[toc] | [prev] | [next] | [standalone]

#264458

[Multipart message — attachments visible in raw view] — view raw

On 12/8/23 17:54, Greg Wooledge wrote:
> On Fri, Dec 08, 2023 at 05:41:57PM -0500, Pocket wrote:
>> On 12/8/23 17:31, Greg Wooledge wrote:
>>> On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
>>>> In Unix and Linux there isn't a file extension, that is a microsoft
>>>> invention.
>>> cc(1) and make(1) would like to have a talk with you.
>>>
>> Linux/Unix filenaming specs would like to inform you.
>>
>> file specs/naming i Unix and Linux are 355 characters and nothing more.
>>
>> I am surprised you don't know that
> cc(1) looks at the file extension to decide what kind of content each
> named argument file is expected to contain.  A .c file is expected to
> contain C language source code; a .o file is expected to contain object
> code; a .s file is expected to contain assembly language source code;
> and so on.  It invokes the compiler, the assembler, and/or the linker
> depending on what kinds of files it has been given.


No it looks for a suffix


>
> make(1) lets you define a rule for converting an input file with extension
> E1 to an output file with extension E2.  These rules will be applied in
> the absence of specific overrides.  If you define a rule like ".xx.yy:"
> then make will use this to turn any *.xx file into a matching *.yy file.
> Then you can type, for example, "make frog.yy" and it will look for
> frog.xx and frog.yy, compare their timestamps, and if needed, apply your
> custom rule to generate the frog.yy file.
>
> While I'm giving examples, there's also Apache, which decides what
> Content-type header to generate for a given static file based on its
> extension.  I would imagine other web servers do the same thing.


Apache is an application that looks for a file suffix

>
> And hey, I'm using mutt to compose and send this email.  If I were to
> attach a file to this message, mutt would look at its extension to
> decide what MIME type to give it.

rename a jpeg to farts, linux still knows it is a jpeg


>
> Your notion that "most Unix programs use file(1) output to decide a file's
> content" is simply not universal.  I don't even think it's *common*,
> especially given how inconsistent file's output is.  Most programs
> that need to determine content types dynamically look at extensions.
> Even on Unix.

Non sense

-- 

It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264459

On Fri, Dec 08, 2023 at 05:59:58PM -0500, Pocket wrote:
> On 12/8/23 17:54, Greg Wooledge wrote:
> > cc(1) looks at the file extension to decide what kind of content each
> > named argument file is expected to contain.

> No it looks for a suffix

So Debian files have "suffixes" and Windows files have "extensions",
and they're identical in form and function, but you use different labels
for them?  OK then.

> rename a jpeg to farts, linux still knows it is a jpeg

Why would the *kernel* know any such thing?  Kernels do not care about
graphical file types.

[toc] | [prev] | [next] | [standalone]

#264461

On 12/8/23 18:17, Greg Wooledge wrote:
> On Fri, Dec 08, 2023 at 05:59:58PM -0500, Pocket wrote:
>> On 12/8/23 17:54, Greg Wooledge wrote:
>>> cc(1) looks at the file extension to decide what kind of content each
>>> named argument file is expected to contain.
>> No it looks for a suffix
> So Debian files have "suffixes" and Windows files have "extensions",
> and they're identical in form and function, but you use different labels
> for them?  OK then.

No "extensions" are required in ms operation systems.

A file spec in Unix/Linux is a string of 255 characters

look it up


>
>> rename a jpeg to farts, linux still knows it is a jpeg
> Why would the *kernel* know any such thing?  Kernels do not care about
> graphical file types.
>
-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264457

On 12/8/23 17:41, Pocket wrote:
>
> On 12/8/23 17:31, Greg Wooledge wrote:
>> On Fri, Dec 08, 2023 at 05:06:15PM -0500, Pocket wrote:
>>> In Unix and Linux there isn't a file extension, that is a microsoft
>>> invention.
>> cc(1) and make(1) would like to have a talk with you.
>>
> Linux/Unix filenaming specs would like to inform you.
>
> file specs/naming i Unix and Linux are 355 characters and nothing more.


file specs/naming in Unix and Linux are 255 characters and nothing more.


>
> I am surprised you don't know that
>
>
-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264454

Greg writes:
> cc(1) and make(1) would like to have a talk with you.

Those are applications and can do whatever they want.  The OS does not
care about extensions.
-- 
John Hasler 
john@sugarbit.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#264456

On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote:
> Greg writes:
> > cc(1) and make(1) would like to have a talk with you.
> 
> Those are applications and can do whatever they want.  The OS does not
> care about extensions.

What do you consider "the OS" to be, then?

[toc] | [prev] | [next] | [standalone]

#264460

On 12/8/23 17:55, Greg Wooledge wrote:
> On Fri, Dec 08, 2023 at 04:50:04PM -0600, John Hasler wrote:
>> Greg writes:
>>> cc(1) and make(1) would like to have a talk with you.
>> Those are applications and can do whatever they want.  The OS does not
>> care about extensions.
> What do you consider "the OS" to be, then?


https://www.britannica.com/technology/operating-system

https://en.wikipedia.org/wiki/Operating_system

https://www.geeksforgeeks.org/what-is-an-operating-system/


>
-- 
It's not easy to be me

[toc] | [prev] | [next] | [standalone]

#264470

On Friday,  8 Dec 2023 at 17:06, Pocket wrote:
> In Unix and Linux there isn't a file extension, that is a microsoft
> invention.

Predates MS by years.  Systems like RSTS/E on PDP-11s, just to name one.
-- 
Eric S Fraga via gnus (Emacs 30.0.50 2023-09-14) on Debian 12.2

[toc] | [prev] | [next] | [standalone]

#264519

On 2023-12-09, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> On Friday,  8 Dec 2023 at 17:06, Pocket wrote:
>> In Unix and Linux there isn't a file extension, that is a microsoft
>> invention.
>
> Predates MS by years.  Systems like RSTS/E on PDP-11s, just to name one.

They certainly are convenient. 

I must be stupid or something.

[toc] | [prev] | [next] | [standalone]

#264522

[Multipart message — attachments visible in raw view] — view raw

On Sun, Dec 10, 2023 at 04:15:22PM -0000, Curt wrote:
> On 2023-12-09, Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> > On Friday,  8 Dec 2023 at 17:06, Pocket wrote:
> >> In Unix and Linux there isn't a file extension, that is a microsoft
> >> invention.
> >
> > Predates MS by years.  Systems like RSTS/E on PDP-11s, just to name one.
> 
> They certainly are convenient. 

When they aren't a lie. Remember those "foo.jpg.exe"?

I always consider putting metadata in a file name a "design smell" [1].

That's why I cringe when people name executables "foo.sh". What do you
do when you decide to rewrite the thing in C (or Rust, or whatever)?

Do you go over all calling sites and change the caller's code?

Cheers

[1] https://en.wikipedia.org/wiki/Code_smell
-- 
t

[toc] | [prev] | [next] | [standalone]

#264547

<tomas@tuxteam.de> wrote:
...
> That's why I cringe when people name executables "foo.sh". What do you
> do when you decide to rewrite the thing in C (or Rust, or whatever)?
>
> Do you go over all calling sites and change the caller's code?

  no, i would just consider it a transition or a change
in versions.  :)

  i was always glad when people wrote descriptive names
for their programs instead of "f" or "f(x)".

  since my first major programs were written in Assembler
Pascal and C whatever extensions needed for those were 
used, i didn't see it as any fault.


  songbird

[toc] | [prev] | [next] | [standalone]

#264548

[Multipart message — attachments visible in raw view] — view raw

On Sun, Dec 10, 2023 at 01:28:20PM -0500, songbird wrote:
> <tomas@tuxteam.de> wrote:
> ...
> > That's why I cringe when people name executables "foo.sh". What do you
> > do when you decide to rewrite the thing in C (or Rust, or whatever)?
> >
> > Do you go over all calling sites and change the caller's code?
> 
>   no, i would just consider it a transition or a change
> in versions.  :)

Again. You have one script, say /usr/local/bin/ring-the-bells.sh
You use it in several other scripts. If you now re-implement it
in your favourite Pascal as ring-the-bells.pas or something, you
go over all your executables and fix that?

IMO an executable name should indicate /what/ an executable does,
not /how/.

>   i was always glad when people wrote descriptive names
> for their programs instead of "f" or "f(x)".

This is something totally different. Call the function by
what it does, but -- again -- not by how.

>   since my first major programs were written in Assembler
> Pascal and C whatever extensions needed for those were 
> used, i didn't see it as any fault.

It is your prerogative, of course. I'm happy that ls is ls
and git, git (not ls.i-was-implemented-in-c or something).

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web