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

Groups > comp.os.linux.misc > #11784 > unrolled thread

composition ? piping

Back to article view | Back to comp.os.linux.misc

Contents

  composition ? piping Unknown <dog@gmail.com> - 2014-08-21 20:50 +0000
    Re: composition ? piping Joe Beanfish <joebeanfish@nospam.duh> - 2014-08-22 13:39 +0000
    Re: composition ? piping John Hasler <jhasler@newsguy.com> - 2014-08-22 10:16 -0500
      Re: composition ? piping Rich <rich@example.invalid> - 2014-08-22 17:13 +0000
      Re: composition ? piping Unknown <dog@gmail.com> - 2014-09-21 13:09 +0000
        Re: composition ? piping Jerry Peters <jerry@example.invalid> - 2014-09-21 20:18 +0000
          Re: composition ? piping Joe Beanfish <joebeanfish@nospam.duh> - 2014-09-22 13:39 +0000
            Re: composition ? piping Michael Baeuerle <michael.baeuerle@stz-e.de> - 2014-09-26 08:26 +0000
              Re: composition ? piping Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-09-26 13:01 -0400
                Re: composition ? piping Michael Baeuerle <michael.baeuerle@stz-e.de> - 2014-09-29 08:54 +0000
                  Re: composition ? piping Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2014-09-29 15:47 +0000
                    Re: composition ? piping John Hasler <jhasler@newsguy.com> - 2014-09-29 11:41 -0500
              Re: composition ? piping "Anonymous Remailer (austria)" <mixmaster@remailer.privacy.at> - 2014-09-27 12:49 +0200
        Re: composition ? piping Bill Marcum <bill.marcum57@yahoo.com> - 2014-09-25 14:58 -0400

#11784 — composition ? piping

Show me the line-count of the newest [by change time] file, 
in the same dir as the executable file:M;
  in a compositional/non*nix syntax might be:
M which | dirname | ls -t | head -1 | cat | wc -l

How is it in this ad hoc *nix mess ?

Also, is 'rename-piping' possible?
eg. instead of:
cp A b.wav; aplay b.wav ; rm b.wav
 aplay `<process file A as fileb.wav would be processed>
?

== TIA.

[toc] | [next] | [standalone]

#11791

On Thu, 21 Aug 2014 20:50:04 +0000, Unknown wrote:

> Show me the line-count of the newest [by change time] file,
> in the same dir as the executable file:M;
>   in a compositional/non*nix syntax might be:
> M which | dirname | ls -t | head -1 | cat | wc -l
> 
> How is it in this ad hoc *nix mess ?

Calling *nix a mess when your utopian "maybe" syntax doesn't even exist
is uncalled for. I know you like to whine and present every question as
a confrontation, but give it a break. Just ask your questions without
the bile.

Below is one way. Replace "M" with the executable name.

execdir="`dirname \`type -p M\``" ;wc -l "$execdir/`ls -t \"$execdir\"|
head -1`"

> 
> Also, is 'rename-piping' possible?
> eg. instead of:
> cp A b.wav; aplay b.wav ; rm b.wav
>  aplay `<process file A as fileb.wav would be processed>

You're asking the wrong question. The question is how to make "aplay"
play a file without a .wav extension. The answer is
   aplay <A
or
   aplay A
It'll figure it out without the extension. At least mine does
$ aplay --version
aplay: version 1.0.27.2 by Jaroslav Kysela <perex@perex.cz>

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

#11793

Unknown writes:
> cp A b.wav; aplay b.wav ; rm b.wav
> aplay `<process file A as fileb.wav would be processed>
> ?

aplay, like any other Unix or Linux program, doesn't give a damn about
suffixes.  "." is just a character and it and the characters after it
are just parts of the filename.  "aplay A" will work fine.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

#11795

John Hasler <jhasler@newsguy.com> wrote:
> Unknown writes:
> > cp A b.wav; aplay b.wav ; rm b.wav
> > aplay `<process file A as fileb.wav would be processed>
> > ?

> aplay, like any other Unix or Linux program, doesn't give a damn about
> suffixes.  "." is just a character and it and the characters after it
> are just parts of the filename.  "aplay A" will work fine.

The OP is likely a windows fanboi, and sadly the braindamage that is
windows trains the unknowing that "the file extension must match"
because nearly every windows program pukes if the extension is
incorrect, as well as pukes if the content is wrong for the extension.

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

#12140

On Fri, 22 Aug 2014 10:16:50 -0500, John Hasler wrote:

> Unknown writes:
>> cp A b.wav; aplay b.wav ; rm b.wav
>> aplay `<process file A as fileb.wav would be processed> ?
> 
> aplay, like any other Unix or Linux program, doesn't give a damn about
> suffixes.  "." is just a character and it and the characters after it
> are just parts of the filename.  "aplay A" will work fine.

I don't promote name-dropping; and <fileTYPES> are often detectable
from their initial bytes [? magic numbers?].

But your statement implies that job.sh SHOULD be handled the same
as jobDOG is 'not good'. That loses a complete dimension.

An extreme case is my ChineseButtonAudioPlayer: it
doesn't even distinguish between directory-nodes.
Apparently it just examines all the files [including <dir-pointers>]
and if it finds one of the File-types-that-it-plays, it plays
that file.

I know for a fact that `mc` pays special attention to <file extentions>.

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

#12142

Unknown <dog@gmail.com> wrote:
> On Fri, 22 Aug 2014 10:16:50 -0500, John Hasler wrote:
> 
>> Unknown writes:
>>> cp A b.wav; aplay b.wav ; rm b.wav
>>> aplay `<process file A as fileb.wav would be processed> ?
>> 
>> aplay, like any other Unix or Linux program, doesn't give a damn about
>> suffixes.  "." is just a character and it and the characters after it
>> are just parts of the filename.  "aplay A" will work fine.
> 
> I don't promote name-dropping; and <fileTYPES> are often detectable
> from their initial bytes [? magic numbers?].
> 
> But your statement implies that job.sh SHOULD be handled the same
> as jobDOG is 'not good'. That loses a complete dimension.

The above statement makes absolutely no sense. I assume job.sh implies
that it's  a shell script and is executable. If jobDOG isn't an
executable that will be readily apparent if you try to execute it. If
you've been stupid enough to make it executable, that's *your* problem

> 
> An extreme case is my ChineseButtonAudioPlayer: it
> doesn't even distinguish between directory-nodes.
> Apparently it just examines all the files [including <dir-pointers>]
> and if it finds one of the File-types-that-it-plays, it plays
> that file.
> 
> I know for a fact that `mc` pays special attention to <file extentions>.

Perhaps because it's a clone of a DOS program?

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

#12144

On Sun, 21 Sep 2014 20:18:45 +0000, Jerry Peters wrote:

> Unknown <dog@gmail.com> wrote:
>> On Fri, 22 Aug 2014 10:16:50 -0500, John Hasler wrote:
>> 
>>> Unknown writes:
>>>> cp A b.wav; aplay b.wav ; rm b.wav aplay `<process file A as
>>>> fileb.wav would be processed> ?
>>> 
>>> aplay, like any other Unix or Linux program, doesn't give a damn about
>>> suffixes.  "." is just a character and it and the characters after it
>>> are just parts of the filename.  "aplay A" will work fine.
>> 
>> I don't promote name-dropping; and <fileTYPES> are often detectable
>> from their initial bytes [? magic numbers?].
>> 
>> But your statement implies that job.sh SHOULD be handled the same as
>> jobDOG is 'not good'. That loses a complete dimension.
> 
> The above statement makes absolutely no sense. I assume job.sh implies
> that it's  a shell script and is executable. If jobDOG isn't an
> executable that will be readily apparent if you try to execute it. If
> you've been stupid enough to make it executable, that's *your* problem
> 
> 
>> An extreme case is my ChineseButtonAudioPlayer: it doesn't even
>> distinguish between directory-nodes.
>> Apparently it just examines all the files [including <dir-pointers>]
>> and if it finds one of the File-types-that-it-plays, it plays that
>> file.
>> 
>> I know for a fact that `mc` pays special attention to <file
>> extentions>.
> 
> Perhaps because it's a clone of a DOS program?

And because it's an interactive human interface. Humans often use
"extensions" to help them organize information. Use of extensions will
persist indefinitely, even if they're not as strictly formalized as
on the old fat filesystem.

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

#12166

Joe Beanfish wrote:
> Jerry Peters wrote:
> > Unknown wrote:
> > > John Hasler wrote:
> > > > Unknown wrote:
> > > > > 
> > > > > cp A b.wav; aplay b.wav ; rm b.wav aplay `<process file A as
> > > > > fileb.wav would be processed> ?
> > > > 
> > > > aplay, like any other Unix or Linux program, doesn't give a damn about
> > > > suffixes.  "." is just a character and it and the characters after it
> > > > are just parts of the filename.  "aplay A" will work fine.
> > > 
> > > I don't promote name-dropping; and <fileTYPES> are often detectable
> > > from their initial bytes [? magic numbers?].
> > > 
> > > But your statement implies that job.sh SHOULD be handled the same as
> > > jobDOG is 'not good'. That loses a complete dimension.
> > 
> > The above statement makes absolutely no sense. I assume job.sh implies
> > that it's  a shell script and is executable. If jobDOG isn't an
> > executable that will be readily apparent if you try to execute it. If
> > you've been stupid enough to make it executable, that's *your* problem
> > 
> > > An extreme case is my ChineseButtonAudioPlayer: it doesn't even
> > > distinguish between directory-nodes.
> > > Apparently it just examines all the files [including <dir-pointers>]
> > > and if it finds one of the File-types-that-it-plays, it plays that
> > > file.
> > > 
> > > I know for a fact that `mc` pays special attention to <file
> > > extentions>.
> > 
> > Perhaps because it's a clone of a DOS program?
> 
> And because it's an interactive human interface. Humans often use
> "extensions" to help them organize information. Use of extensions will
> persist indefinitely, even if they're not as strictly formalized as
> on the old fat filesystem.

This is not even the "wrong" thing. Unix has a bit in the inodes that
indicate whether a file is executable, but there is no field for
something like a "content type". Therefore the content of any non-
executable file is unknown from the filesystems view.

Whether look inside to guess what the content is likely to be or look
at the extension of the name to see what label is on the outside are
both working but can be fooled if this is intended.

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

#12167

On Friday 26 September 2014 04:26, in comp.os.linux.misc, "Michael Baeuerle"
<michael.baeuerle@stz-e.de> wrote:

> Joe Beanfish wrote:
[snip]
>> Humans often use
>> "extensions" to help them organize information. Use of extensions will
>> persist indefinitely, even if they're not as strictly formalized as
>> on the old fat filesystem.
> 
> This is not even the "wrong" thing. Unix has a bit in the inodes that
> indicate whether a file is executable, but there is no field for
> something like a "content type". Therefore the content of any non-
> executable file is unknown from the filesystems view.
> 
> Whether look inside to guess what the content is likely to be or look
> at the extension of the name to see what label is on the outside are
> both working but can be fooled if this is intended.

When trying to determine the content of a file, which makes more sense:
1) look at a component of the filename and guess it's significance (it might
   be wrong or misleading), or
2) to look at the content of the file?

To me, it makes more sense to see what's in the file, rather than guess it's
contents based on an arbitrary textual value assigned as the file's name.

Note also that a Linux file can have many different names, some of which are
guaranteed /not/ to indicate the file's contents. Consider

  12:47 $ ls -l Guy_Fawkes_mask*
  -rw-r--r-- 2 lpitcher users 40615 2012-02-07 09:08 Guy_Fawkes_mask
  -rw-r--r-- 2 lpitcher users 40615 2012-02-07 09:08 Guy_Fawkes_mask.png

  12:48 $ file Guy_Fawkes_mask*
  Guy_Fawkes_mask:          PNG image data, 675 x 800, 8-bit/color RGBA,
                            non-interlaced
  Guy_Fawkes_mask.png:      PNG image data, 675 x 800, 8-bit/color RGBA,
  non-interlaced

which makes sense, because Guy_Fawkes_mask and Guy_Fawkes_mask.png are
(hardlinked names to) the same file.

As for executables, even the kernel inspects the contents of the executable
file to determine it's format and contents. What you need is to use the
kernel's binfmt_misc interface, and register an execution interpreter for
the specific file contents. Once that's done, you chmod a+x your file, and
execute it from the commandline

The /proc/sys/fs/binfmt_misc/ tree only exists when you enable the
binfmt_misc kernel module, and mount the binfmt_misc filesystem.

In this directory tree there will be a file called "register"
(/proc/sys/fs/binfmt_misc/register), which is a text file into which you
write details about each executable file format, and the kernel or user
binary that will load and execute it. When the kernel is asked to exec() a
file, it compares the file contents to the rules written in
binfmt_misc/register, and selects the appropriate loader/interpreter for
the file.

This is how (for instance) java files can be executed from the commandline
without directly invoking the java interpreter.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#12186

Lew Pitcher wrote:
> Michael Baeuerle wrote:
> > Joe Beanfish wrote:
> [snip]
> > > Humans often use
> > > "extensions" to help them organize information. Use of extensions will
> > > persist indefinitely, even if they're not as strictly formalized as
> > > on the old fat filesystem.
> > 
> > This is not even the "wrong" thing. Unix has a bit in the inodes that
> > indicate whether a file is executable, but there is no field for
> > something like a "content type". Therefore the content of any non-
> > executable file is unknown from the filesystems view.
> > 
> > Whether look inside to guess what the content is likely to be or look
> > at the extension of the name to see what label is on the outside are
> > both working but can be fooled if this is intended.
> 
> When trying to determine the content of a file, which makes more sense:
> 1) look at a component of the filename and guess it's significance (it might
>    be wrong or misleading), or
> 2) to look at the content of the file?
> 
> To me, it makes more sense to see what's in the file, rather than guess it's
> contents based on an arbitrary textual value assigned as the file's name.

I agree that for a general solution looking inside the file would give
better results.

But there are also some points against it:
- Looking into a file is much slower than looking at its name
  This is not relevant for a single file, but maybe for processing
  100000 files.
- There are file types without a container format where it may be hard
  to impossible to determine the data type from looking at the content.
- No utility like "file" will ever have knowledge about all file types
  that are used in the wild.
- The name is always shown to the user (if a system doesn't do broken
  things like Windows explorer with hiding the extension).
 
> Note also that a Linux file can have many different names, some of which are
> guaranteed /not/ to indicate the file's contents. Consider
> 
>   12:47 $ ls -l Guy_Fawkes_mask*
>   -rw-r--r-- 2 lpitcher users 40615 2012-02-07 09:08 Guy_Fawkes_mask
>   -rw-r--r-- 2 lpitcher users 40615 2012-02-07 09:08 Guy_Fawkes_mask.png
> 
>   12:48 $ file Guy_Fawkes_mask*
>   Guy_Fawkes_mask:          PNG image data, 675 x 800, 8-bit/color RGBA,
>                             non-interlaced
>   Guy_Fawkes_mask.png:      PNG image data, 675 x 800, 8-bit/color RGBA,
>   non-interlaced
> 
> which makes sense, because Guy_Fawkes_mask and Guy_Fawkes_mask.png are
> (hardlinked names to) the same file.

I agree for this case. But consider a custom file format of a company
that "file" don't know. The company maybe want to indicate the file type
to make it easier for their customers to find or identify such files
(something like "ls -l *.xyz" is much simpler and faster than "show me
all files which content looks like xyz").

> As for executables, even the kernel inspects the contents of the executable
> file to determine it's format and contents. What you need is to use the
> kernel's binfmt_misc interface, and register an execution interpreter for
> the specific file contents. Once that's done, you chmod a+x your file, and
> execute it from the commandline

Yes, and this is good behaviour until it only works with the "x" bit set
in the metadata. I don't want to justify things like detecting
executables via the extension ".EXE"!

But for normal users (especially former Windows users) it is sometimes
convenient to have *data* files (that are not executable) with
extensions that labels their content.

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

#12189

On 2014-09-29, Michael Baeuerle <michael.baeuerle@stz-e.de> wrote:

> Lew Pitcher wrote:
>
>> When trying to determine the content of a file, which makes more sense:
>> 1) look at a component of the filename and guess it's significance (it might
>>    be wrong or misleading), or
>> 2) to look at the content of the file?
>> 
>> To me, it makes more sense to see what's in the file, rather than guess it's
>> contents based on an arbitrary textual value assigned as the file's name.

<snip>

> I agree for this case. But consider a custom file format of a company
> that "file" don't know. The company maybe want to indicate the file type
> to make it easier for their customers to find or identify such files
> (something like "ls -l *.xyz" is much simpler and faster than "show me
> all files which content looks like xyz").

There's nothing that says you can't have conventions for file suffixes;
indeed, most of us agree this is a Good Thing.  But Windows gives them
far too much weight.

>> As for executables, even the kernel inspects the contents of the executable
>> file to determine it's format and contents. What you need is to use the
>> kernel's binfmt_misc interface, and register an execution interpreter for
>> the specific file contents. Once that's done, you chmod a+x your file, and
>> execute it from the commandline
>
> Yes, and this is good behaviour until it only works with the "x" bit set
> in the metadata. I don't want to justify things like detecting
> executables via the extension ".EXE"!

Yet this is the logical consequence of depending on file extensions -
especially considering how fond Microsoft is of broken designs.

> But for normal users (especially former Windows users) it is sometimes
> convenient to have *data* files (that are not executable) with
> extensions that labels their content.

Again, few of us, as strongly as we push for content-based file typing,
would deny that file suffix conventions are useful.  (Note the subtle
distinction between "suffix" and "extension".)  We just feel that it
should not be the sole - or critical - determinant.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

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

#12190

Charlie Gibbs writes:
> Again, few of us, as strongly as we push for content-based file
> typing, would deny that file suffix conventions are useful.  (Note the
> subtle distinction between "suffix" and "extension".)  We just feel
> that it should not be the sole - or critical - determinant.

Yes.  The "." is ok as a visual delimiter but it should have no
significance to the file system.  I should be able to name all my
photographs "<something>.picture" without confusing any of my software.
-- 
John Hasler 
jhasler@newsguy.com
Dancing Horse Hill
Elmwood, WI USA

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

#12168

Joe Beanfish [JB]:
JB> Humans often use "extensions" to help them organize information. Use
JB> of extensions will persist indefinitely, even if they're not as
JB> strictly formalized as on the old fat filesystem.

It could be that humans use "extensions", only after they have been
exposed to VMS/DOS/Windows computers and learned those systems' way of
doing things. Discrete filesystem hierarchies (A:, C:, E:) is
another such thing.

Lew Pitcher <lew.pitc...@digitalfreehold.ca> [LP]:
LP> it makes more sense to see what's in the file, rather than
LP> guess its contents based on an arbitrary textual value assigned as the
LP> file's name.

I totally agree. Another problem with DOS extensions is that you can
only have 26 x 27 x 27 = 18954 different file types (26
case-insensitive characters, or nothing in the last two positions) for
3-character long extensions. This number has already been exceeded and
some extensions are used for more than one file types, which clearly
cancels any advantage of using them as definite content
differentiators.

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

#12164

On 09/21/2014 09:09 AM, Unknown wrote:
>
> I know for a fact that `mc` pays special attention to <file extentions>.
>
You can customize how mc handles different files, matching extensions
or 'file' command output, by editing the mc.ext file.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web