should we keep the commandline pipe tradition?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

should we keep the commandline pipe tradition?

Zhang Weiwu, Beijing
Hi. I haven't been using commandline extensively for some years, and
when I come back to Linux, I was surprised to see GUI software being
developed so fast and so well on Linux (and feel happy about it).
However I wonder if current commandlin isn't as useful as was.

e.g. in order to play midi music keyboard I instantly think of doing this:

$ timidity < /dev/midi

timidity is the player that generate sounds from midi events. /dev/midi
is the device that produce such events, like /dev/ttyS0 when connected
to a mouse.

And I was told no, that's not the way it is. correct way is:

$ timidity -AD          # put to daemon mode
$ aconnect 16:0 128:0
# 16:0 is another way to represent /dev/midi
# while 128:0 is the virtual device that generates sound


Another example: when I wanted to join multiple TIFF images into a
single multi-page tiff image, I thought I could do this:

$ tiffcat < page-1.tiff page-2.tiff page-3.tiff page-4.tiff > pages.tiff

And I was told no. The right way to do it is:

$ tiffcp page-1.tiff page-2.tiff page-3.tiff page-4.tiff pages.tiff

The problem of tiffcp is I have to use the temporary files, otherwise I
could pipe the output of the command that generated these page-?.tiff,
like this:

$ (cmd1; cmd2; cmd3) | tiffcp > pages.tiff

I was wondering if pipe is now being used less as it was used to be or
should be, and is this something good or bad?
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Per Jessen-2
Zhang Weiwu wrote:

> However I wonder if current commandlin isn't as useful as was.

If anything, it might even be more useful now.

> e.g. in order to play midi music keyboard I instantly think of doing
> this:
>
> $ timidity < /dev/midi
>

I use "pmidi", e.g. pmidi file...

> I was wondering if pipe is now being used less as it was used to be or
> should be, and is this something good or bad?

Piping is not being used any less now than at any other time.


/Per

--
Per Jessen, Zürich (28.5°C)

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Adam Tauno Williams
In reply to this post by Zhang Weiwu, Beijing
On Mon, 2009-07-27 at 23:24 +0800, Zhang Weiwu wrote:
> Hi. I haven't been using commandline extensively for some years, and
> when I come back to Linux, I was surprised to see GUI software being
> developed so fast and so well on Linux (and feel happy about it).
> However I wonder if current commandlin isn't as useful as was.

Yes, but it also has the same shortcomings it always had.

> $ timidity -AD          # put to daemon mode
> $ aconnect 16:0 128:0
> # 16:0 is another way to represent /dev/midi
> # while 128:0 is the virtual device that generates sound

But I don't even have a /dev/midi.  Part of this may be because
the /dev/ filesystem is such a pain.  Devices aren't files and treating
them as such is just odd, you end up with lots of weird device specific
ioctl() calls and on systems with many devices or devices that change
frequently the old /dev/xyz0 ... /dev/xyz9999 also gets clunky.  So the
above may not have anything to do with pipe-love but just the realities
of modern device management.

> Another example: when I wanted to join multiple TIFF images into a
> single multi-page tiff image, I thought I could do this:
> $ tiffcat < page-1.tiff page-2.tiff page-3.tiff page-4.tiff > pages.tiff
> And I was told no. The right way to do it is:
> $ tiffcp page-1.tiff page-2.tiff page-3.tiff page-4.tiff pages.tiff
> The problem of tiffcp is I have to use the temporary files, otherwise I
> could pipe the output of the command that generated these page-?.tiff,
> like this:
> $ (cmd1; cmd2; cmd3) | tiffcp > pages.tiff

Which might be making temp files anyway; now they are just asking you to
do it.  A pipe is a read only (or write only) sequential stream,  you
can't seek it, which makes processing some types of data a pain.  Also
piping as described aggregates all the data (BLOBs really in this case)
and perhaps the utility needs to now the start and end of each BLOB
which the process of piping has obscured.

> I was wondering if pipe is now being used less as it was used to be or
> should be, and is this something good or bad?

It is used a lot.  But, at the risk of being flamed like crazy, the UNIX
pipe & shell certainly does seem primitive next to object piping
supported in Microsoft Powershell (and some other proprietary known
CLIs).  Sadly I'm not aware of any Open Source OO shells and PASH
<http://pash.sourceforge.net/> seems dead in the water.  Due to so much
of the modern BLOB oriented (non-text) data and network oriented stuff I
find myself using Python or something like Boo way more than the UNIX
shell for both scripting and interactive work.  If you want to work with
files and information I certainly wouldn't go to shell anymore except
for really basic stuff.  In an OO shell you can tread an image like an
image, a mail message like a mail message, etc... and not have to hack
around so much.

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Per Jessen-2
Adam Tauno Williams wrote:

>> I was wondering if pipe is now being used less as it was used to be
>> or should be, and is this something good or bad?
>
> It is used a lot.  But, at the risk of being flamed like crazy, the
> UNIX pipe & shell certainly does seem primitive next to object piping
> supported in Microsoft Powershell (and some other proprietary known
> CLIs).

Never even heard about it.  But VM/CMS pipes are at least 10 years old
and were even then more powerful than what we have in todays bash et
al.

> Due to so much of the modern BLOB oriented (non-text) data and network
> oriented stuff I find myself using Python or something like Boo way
> more than the UNIX shell for both scripting and interactive work.

Never heard of Boo either, but for scripting and prototyping, I use bash
and php.


/Per

--
Per Jessen, Zürich (27.6°C)

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Randall Schulz
In reply to this post by Zhang Weiwu, Beijing
On Monday July 27 2009, Zhang Weiwu wrote:

> Hi. I haven't been using commandline extensively for some years, and
> when I come back to Linux, I was surprised to see GUI software being
> developed so fast and so well on Linux (and feel happy about it).
> However I wonder if current commandlin isn't as useful as was.
>
> ...
>
>
> Another example: when I wanted to join multiple TIFF images into a
> single multi-page tiff image, I thought I could do this:
>
> $ tiffcat < page-1.tiff page-2.tiff page-3.tiff page-4.tiff >
> pages.tiff

I'm not sure what this is supposed to do or what you imagine it does,
but if you think that tiffcat is getting the contents of page-2.tiff
through page-4.tiff, you're mistaken. File redirection in the shell
only operates on a single file. Further, and many people don't realize
this, file redirection (but not piping) can appear anywhere in the
command and need not be at the end or the beginning.

If in the preceding command line you want tiffcat to read the contents
of all four TIFF files on its standard input, this will work:

% cat page-{1,2,3,4}.tiff |tiffcat

If tiffcat, e.g., accepts only a single named argument and will not read
its standard input, this will work:

% tiffcat <( cat page{1,2,3,4}.tiff )

This syntax, <( command ), makes the output of "command" appear as a
named file argument (but is actually a named pipe). Note that for some
programs (kdiff3 and Vim are two I know of) this won't work because the
program wants to read the input more than once (i.e., it wants to seek
within the file, which pipes do not support), so if you get odd
behavior when using this construct, that can be the reason. Because of
this, I wrote a wrapper that I can use when a random-access file is
required and I want to use the <( ... ) notation.


> ...


Randall Schulz


--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Jim Henderson-4
In reply to this post by Zhang Weiwu, Beijing
On Mon, 27 Jul 2009 23:24:35 +0800, Zhang Weiwu wrote:

> I was wondering if pipe is now being used less as it was used to be or
> should be, and is this something good or bad?

I use piping every day.  If you don't, then don't use it, but it doesn't
seem like anyone's really in a position to say "let's do away with it
completely".

Jim



--
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

M Harris-2
In reply to this post by Per Jessen-2
On Monday 27 July 2009 12:00, Per Jessen wrote:
> Never even heard about it.  But VM/CMS pipes are at least 10 years old
> and were even then more powerful than what we have in todays bash et
> al.

        VM/ESA CMS Pipelines (Release 2) dates back to 1992. Early CMS Pipelines
dates back to the mid 1980's.
        I have been playing around with a *nix port of "Pipelines" in my spare time
because the pipelines concept is so powerful for processing table-based text
files (flat text database files), and is less cryptic for newbies than
learning regular expressions.
        Back in the day we (VMers) would build REXX shells around CMS Pipelines for
processing text. They were powerful and yet were not as cryptic as unix pipes
containing regular expressions.
        On the other hand, if you take the time to learn a little Pearl and regular
expressions you can do all the same stuff as CMS Pipelines (with the
exception that secondary and tertiary pipelines in CMS is easier to code and
more efficient.
       












--
Kind regards,

M Harris     <><
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

M Harris-2
In reply to this post by Zhang Weiwu, Beijing
On Monday 27 July 2009 10:24, Zhang Weiwu wrote:
> Hi. I haven't been using commandline extensively for some years, and
> when I come back to Linux, I was surprised to see GUI software being
> developed so fast and so well on Linux (and feel happy about it).
> However I wonder if current commandlin isn't as useful as was.
        CLI is very much alive and well in the linux world, but isn't for everyone
and isn't necessary or desireable in many situations.
        Desktops are great and gui (CUI) is fine; I use 'em all the time. BUT, to
pull the raw power from a *nix system requires a CLI at some point.
        CLI terminals are essential for remote system maintenance in most situations;
and for maintenance on any system when the display/desktop won't come up for
some reason.
        Modern versions of BASH and KSH are both fine as shells. Konsole is a good
terminal.











--
Kind regards,

M Harris     <><
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Zhang Weiwu, Beijing
In reply to this post by Per Jessen-2
Per Jessen wrote:

> Zhang Weiwu wrote:
>  
>> e.g. in order to play midi music keyboard I instantly think of doing
>> this:
>>
>> $ timidity < /dev/midi
>>    
>
> I use "pmidi", e.g. pmidi file...
>  

What do you do when you want to play from midi device, say, if you have
a midi keyboard?
--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Zhang Weiwu, Beijing
In reply to this post by Zhang Weiwu, Beijing
Zhang Weiwu wrote:
> Hi. I haven't been using commandline extensively for some years, and
> when I come back to Linux, I was surprised to see GUI software being
> developed so fast and so well on Linux (and feel happy about it).
> However I wonder if current commandlin isn't as useful as was.
>  


Hi. Let me summarize the discussion.

My two examples and the original question why in the two cases the
implementer choose to use methods other than pipe for the task I thought
would be done using pipe, were never addressed directly. However Adam
Tauno Williams point out:

   1. pipes are not optimized for blob data which is true in both
      examples, and introduced object-oriented piping which exists in
      Micrsoft Powershell and VMS.
   2. reading devices as file is also not optimal.

I find these input very informative.

Randall R Schulz explained some important advanced use of pipe and how
things work. Thanks.

Other people told me they use pipe all the time without mentioning why
the two cases, both does not exist in UNIX when pipe concept was created
(and thus are new usages), was designed not to use pipe following
traditional convention.


--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Peter Nikolic
On Wednesday 29 Jul 2009 04:36:47 Zhang Weiwu wrote:

> Zhang Weiwu wrote:
> > Hi. I haven't been using commandline extensively for some years, and
> > when I come back to Linux, I was surprised to see GUI software being
> > developed so fast and so well on Linux (and feel happy about it).
> > However I wonder if current commandlin isn't as useful as was.
>
> Hi. Let me summarize the discussion.
>
> My two examples and the original question why in the two cases the
> implementer choose to use methods other than pipe for the task I thought
> would be done using pipe, were never addressed directly. However Adam
> Tauno Williams point out:
>
>    1. pipes are not optimized for blob data which is true in both
>       examples, and introduced object-oriented piping which exists in
>       Micrsoft Powershell and VMS.
>    2. reading devices as file is also not optimal.
>
> I find these input very informative.
>
> Randall R Schulz explained some important advanced use of pipe and how
> things work. Thanks.
>
> Other people told me they use pipe all the time without mentioning why
> the two cases, both does not exist in UNIX when pipe concept was created
> (and thus are new usages), was designed not to use pipe following
> traditional convention.

There is a simple rule here .. as follows

" Don't Fix What Ain't Broken"

And suse people of all should get the meaning of with any problem after the
farcical  contrivances  of KDE4.x.x

Pete .


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: should we keep the commandline pipe tradition?

Per Jessen-2
In reply to this post by Zhang Weiwu, Beijing
Zhang Weiwu wrote:

> Per Jessen wrote:
>> Zhang Weiwu wrote:
>>  
>>> e.g. in order to play midi music keyboard I instantly think of doing
>>> this:
>>>
>>> $ timidity < /dev/midi
>>>    
>>
>> I use "pmidi", e.g. pmidi file...
>>  
>
> What do you do when you want to play from midi device, say, if you
> have a midi keyboard?

Oh, I didn't even notice you said "keyboard" - I have no idea how to do
that.  I wouldn't expect that to be a command-line function really.


/Per

--
Per Jessen, Zürich (17.6°C)

--
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]