[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $(file) can't read files

From: Tim Murphy
Subject: Re: $(file) can't read files
Date: Sun, 31 May 2015 11:44:13 +0100

On 30 May 2015 at 19:02, Paul Smith <address@hidden> wrote:
On Wed, 2015-05-27 at 07:50 +0100, Tim Murphy wrote:
> $(shell cat filename) is also often used to read files into variables.
> There isn't much reason why $(file <) shouldn't read a file though is
> there?   It would have the additional benefit of being platform
> independent.

This would not be difficult.  There is one question to be answered:
should the results of reading a file be verbatim (including newlines)?
or should it be condensed, like the output of the $(shell ...) function,
where newlines are converted to spaces?

That is a very tough question :/

Personally I would much prefer for this to be possible:

   $(file >copy,$(file <original))

I think it's more useful in the long run.  (the output file would match the input one).

Ok, it could possibly be based on text (translating crlf to lf) but that really wouldn't match how $(shell cat xxx) works.

On the whole I think it would be better NOT to convert newlines to spaces. If there is some desperate reason why that is critical then another function could do it.

One can already create and manipulate multiline strings using "define" so it's not as if such data is foreign to make or as if we would never have a reason to need new functions that can deal with it e.g. $(compresslines) or whatever you might imagine.

So I really like this to be possible: $(file >copy,$(file <original))



You could help some brave and decent people to have access to uncensored news by making a donation at:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]