Hi All,

      How do you read a pipe with a bash script?

Many thanks,
-T

This does not work

echo 123 | eraseme2.sh

$ more eraseme2.sh
#!/bin/bash
echo $1

On 2016-10-18 03:57, T wrote:
> Hi All,
> 
>      How do you read a pipe with a bash script?
> 
> Many thanks,
> -T
> 
> This does not work
> 
> echo 123 | eraseme2.sh
> 
> $ more eraseme2.sh
> #!/bin/bash
> echo $1

You are reading the first parameter, not the pipe. You have to read the
pipe in the same way as you would read the keyboard. The input.

-- 
Cheers, Carlos.

At Mon, 17 Oct 2016 18:57:07 -0700 T <T@invalid.invalid> wrote:

> 
> Hi All,
> 
>       How do you read a pipe with a bash script?
> 
> Many thanks,
> -T
> 
> This does not work
> 
> echo 123 | eraseme2.sh

Try this:

chmod +x eraseme2.sh 
echo 123 | ./eraseme2.sh

> 
> $ more eraseme2.sh
> #!/bin/bash
> echo $1
>           

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                                        

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

T. [2016-10-17 18:57:07-07] wrote:

> How do you read a pipe with a bash script?

You can use any program that reads the standard input ("pipe").

    #!/bin/sh
    cat

or

    #!/bin/sh
    sed -e s/./X/g

There's also "read" command which is useful for storing the content in a
shell variable.

    #!/bin/sh
    while read -r line; do
            echo "Line is: $line"
    done

Note that I used /bin/sh here because these particular examples don't
require any Bash extensions. The examples work in /bin/bash too.

=2D-=20
/// Teemu Likonen   - .-..   <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYBbvTAAoJEHGdadMkU5RQE84QAIetoccnX+N54kRcEwakGiLp
COMl0a4nQv46LfICcVbPg95vvgzeqZSoHiIGth99l8+h2YFC0vG9x3mwJ0SEQNjR
F6Xv7S8jnvARlmVuJTvpyAIWBMC4if643dxWi0oiQ2s6K3ND3R1fQcY7kG3aaxBd
wjxDYafzw0rSJ506XtzPXN2ldyBJjCoJzZ2KPOf8CvNH8IuJQY5lhUe6UoLRwshY
MBzrAVFyS8UATIUPTkquYXcU2GctBaYaadYvor23kAvQVrDvZ77b+mG5AqI/+dOq
9076dWAuFKRpbmvl2llPHmtBZYLVHYS91kdcXGMV7k8UANsSj+/FwXZAJKMTZjw/
OBe+KTNkgfWik1MRCLPSAq2IfRY+ncm7H1ceFofOXaK/8sttzJ/GwKh2ziqgjKLt
SLKIRvp1TcK5l/WO5ALQlzwADh93RcDSYMWbIWmjRDUpqWO12sRM8WQQ7tVp/WZJ
rlS+yQM7boei8dwKRy2OpGk/m9/emtetAtb+NSoGsC1RMoISBlvyQ++TKu3EuJIb
wsJ7NgFFBqjnphNLd9Jy9AAdM4F/0YRsaNAYGKIWLZ5T/sbOCP/wr4u90gkuhheQ
4C0Dout0IT1oLixbfkKb3Q4lObceDlGRa2ZqNRUq8VLpYAFIw78zB38jzZ0Iv73a
bgr8oIOZQ9Z9nu3seZRc
=rV3Y
-----END PGP SIGNATURE-----
--=-=-=--

On 10/17/2016 11:06 PM, Teemu Likonen wrote:
> T. [2016-10-17 18:57:07-07] wrote:
>
>> How do you read a pipe with a bash script?
>
> You can use any program that reads the standard input ("pipe").
>
>     #!/bin/sh
>     cat
>
> or
>
>     #!/bin/sh
>     sed -e s/./X/g
>
> There's also "read" command which is useful for storing the content in a
> shell variable.
>
>     #!/bin/sh
>     while read -r line; do
>             echo "Line is: $line"
>     done
>
> Note that I used /bin/sh here because these particular examples don't
> require any Bash extensions. The examples work in /bin/bash too.
>

Thank you!

On 2016-10-18, T <T@invalid.invalid> wrote:
> Hi All,
>
>       How do you read a pipe with a bash script?
>
> Many thanks,
> -T
>
> This does not work
>
> echo 123 | eraseme2.sh

Sure it does. You just did not write the script properly to read from
stdin if no filename is given.


>
> $ more eraseme2.sh
> #!/bin/bash
> echo $1

stdin s NOT $1. You have no first argument. You have to tell the script
that if there is no first arbument, to read from stdin.

On 10/18/2016 01:59 AM, William Unruh wrote:
> On 2016-10-18, T <T@invalid.invalid> wrote:
>> Hi All,
>>
>>       How do you read a pipe with a bash script?
>>
>> Many thanks,
>> -T
>>
>> This does not work
>>
>> echo 123 | eraseme2.sh
>
> Sure it does.

That is clearly not what I meant.

> You just did not write the script properly to read from
> stdin if no filename is given.
>
>
>>
>> $ more eraseme2.sh
>> #!/bin/bash
>> echo $1
>
> stdin s NOT $1. You have no first argument. You have to tell the script
> that if there is no first arbument, to read from stdin.
>
>

I wonder why everyone are so grumpy today?

In article <nu69qf$b8t$2@dont-email.me>, T  <T@invalid.invalid> wrote:
>On 10/18/2016 01:59 AM, William Unruh wrote:
>> On 2016-10-18, T <T@invalid.invalid> wrote:
>>> Hi All,
>>>
>>>       How do you read a pipe with a bash script?
>>>
>>> Many thanks,
>>> -T
>>>
>>> This does not work
>>>
>>> echo 123 | eraseme2.sh
>>
>> Sure it does.
>
>That is clearly not what I meant.

Of course not.  But this is business as usual on Usenet.
Did you expect anything different?

Anyway, I think what you are looking for is:

[ $# = 0 ] && set -- $(cat)

This says that if no args were passed, then build up the arg list from the
contents of the standard input.

-- 
The plural of "anecdote" is _not_ "data".

On 10/18/2016 06:25 PM, Kenny McCormack wrote:
> In article <nu69qf$b8t$2@dont-email.me>, T  <T@invalid.invalid> wrote:
>> On 10/18/2016 01:59 AM, William Unruh wrote:
>>> On 2016-10-18, T <T@invalid.invalid> wrote:
>>>> Hi All,
>>>>
>>>>       How do you read a pipe with a bash script?
>>>>
>>>> Many thanks,
>>>> -T
>>>>
>>>> This does not work
>>>>
>>>> echo 123 | eraseme2.sh
>>>
>>> Sure it does.
>>
>> That is clearly not what I meant.
>
> Of course not.  But this is business as usual on Usenet.
> Did you expect anything different?
>
> Anyway, I think what you are looking for is:
>
> [ $# = 0 ] && set -- $(cat)
>
> This says that if no args were passed, then build up the arg list from the
> contents of the standard input.
>

Hi Kenny,

Perfect!  Thank you!  I was wonder what would happen if no
data was sent to the pipe.

I am fuzzy about what "set -- $(cat)" does.  I know that
"--" is stdin and "$(cat)" means to run the "cat" command
and resolve it as a string.  But what is "set" doing and where
does the data go?

What would I do to the above to transfer the data to a variable?

Many thanks,
-T

T <T@invalid.invalid> wrote:
> On 10/18/2016 06:25 PM, Kenny McCormack wrote:
>> In article <nu69qf$b8t$2@dont-email.me>, T  <T@invalid.invalid> wrote:
>>> On 10/18/2016 01:59 AM, William Unruh wrote:
>>>> On 2016-10-18, T <T@invalid.invalid> wrote:
>>>>> Hi All,
>>>>>
>>>>>       How do you read a pipe with a bash script?
>>>>>
>>>>> Many thanks,
>>>>> -T
>>>>>
>>>>> This does not work
>>>>>
>>>>> echo 123 | eraseme2.sh
>>>>
>>>> Sure it does.
>>>
>>> That is clearly not what I meant.
>>
>> Of course not.  But this is business as usual on Usenet.
>> Did you expect anything different?
>>
>> Anyway, I think what you are looking for is:
>>
>> [ $# = 0 ] && set -- $(cat)
>>
>> This says that if no args were passed, then build up the arg list from the
>> contents of the standard input.
>>
> 
> Hi Kenny,
> 
> Perfect!  Thank you!  I was wonder what would happen if no
> data was sent to the pipe.
> 
> I am fuzzy about what "set -- $(cat)" does.  I know that
> "--" is stdin and "$(cat)" means to run the "cat" command
> and resolve it as a string.  But what is "set" doing and where
> does the data go?

Don't guess, read the documentation (man bash).  Which states, in the
pertinent part (the part documenting the "set" command):

    --      If no arguments follow this option, then the positional
            parameters are unset.  Otherwise, the positional parameters
            are set to the args, even if some of them begin with a -.

> What would I do to the above to transfer the data to a variable?

The above already transfers the data to a variable.  $1, $2, $3, $4,
etc.  (the positional parameters, which are just variables to the
script), get set to each word in the data sent over the pipe.

But as you've not yet told us specifically what you are trying to do,
the above _may_ not be what you are looking to accomplish.

On 10/18/2016 04:05 PM, T wrote:
> On 10/18/2016 01:59 AM, William Unruh wrote:
>> On 2016-10-18, T <T@invalid.invalid> wrote:
>>> Hi All,
>>>
>>> How do you read a pipe with a bash script?
>>>
>>> Many thanks, -T
>>>
>>> This does not work
>>>
>>> echo 123 | eraseme2.sh
>>
>> Sure it does.
>
> That is clearly not what I meant.
>
>> You just did not write the script properly to read from stdin if no
>> filename is given.
>>>
>>> $ more eraseme2.sh #!/bin/bash echo $1
>>
>> stdin s NOT $1. You have no first argument. You have to tell the
>> script that if there is no first arbument, to read from stdin.
>
> I wonder why everyone are so grumpy today?

Well, we spent a lot of time fixing the toilet today...

-- 
Cheers, Bev
   Life's journey is not to arrive at the grave safely and in a
   well preserved body, but to skid in sideways, totally worn out,
   and shouting HOLY SHIT, WHAT A RIDE!!!

On 10/18/2016 07:59 PM, Rich wrote:
> T <T@invalid.invalid> wrote:
>> On 10/18/2016 06:25 PM, Kenny McCormack wrote:
>>> In article <nu69qf$b8t$2@dont-email.me>, T  <T@invalid.invalid> wrote:
>>>> On 10/18/2016 01:59 AM, William Unruh wrote:
>>>>> On 2016-10-18, T <T@invalid.invalid> wrote:
>>>>>> Hi All,
>>>>>>
>>>>>>       How do you read a pipe with a bash script?
>>>>>>
>>>>>> Many thanks,
>>>>>> -T
>>>>>>
>>>>>> This does not work
>>>>>>
>>>>>> echo 123 | eraseme2.sh
>>>>>
>>>>> Sure it does.
>>>>
>>>> That is clearly not what I meant.
>>>
>>> Of course not.  But this is business as usual on Usenet.
>>> Did you expect anything different?
>>>
>>> Anyway, I think what you are looking for is:
>>>
>>> [ $# = 0 ] && set -- $(cat)
>>>
>>> This says that if no args were passed, then build up the arg list from the
>>> contents of the standard input.
>>>
>>
>> Hi Kenny,
>>
>> Perfect!  Thank you!  I was wonder what would happen if no
>> data was sent to the pipe.
>>
>> I am fuzzy about what "set -- $(cat)" does.  I know that
>> "--" is stdin and "$(cat)" means to run the "cat" command
>> and resolve it as a string.  But what is "set" doing and where
>> does the data go?
>
> Don't guess, read the documentation (man bash).  Which states, in the
> pertinent part (the part documenting the "set" command):
>
>     --      If no arguments follow this option, then the positional
>             parameters are unset.  Otherwise, the positional parameters
>             are set to the args, even if some of them begin with a -.

Hi Rich,

Okay, "set" has its own meaning for "--".  I was thinking
of curl, which uses "--" to signify stdout.  Thank you!

>> What would I do to the above to transfer the data to a variable?
>
> The above already transfers the data to a variable.  $1, $2, $3, $4,
> etc.  (the positional parameters, which are just variables to the
> script), get set to each word in the data sent over the pipe.
>
> But as you've not yet told us specifically what you are trying to do,
> the above _may_ not be what you are looking to accomplish.


Well, originally I was doing something with Lotus Script that
involved a system call (Lotus script called is "Shell") to
a bash script that used a pipe, then changed my mind.

 From there I realized I need to know how to do this for
future reference.  So what I am after is what I call
a "Keeper" (a.k.a. How To) file that explains the process.
Your explanation on the set command and -- will be in it.

To get Keeper finalized, I want to make a sample script that
shows the process.

In common language (not bash), this is what I want from
the script is

if a command line parameter(s) exist, write the(m) out and
where it/they came from (from parameters on the command line)

else if a pipe existed, write it out and where it came from
(from a pipe)

else if neither existed, state such (no hanging waiting
for something that is not there -- very important)

Thank you for the help on this,
-T

If you think Perl is a write only language, I suggest if
you ever come across Lotus Script that you RUN LIKE HELL!

On 10/18/2016 09:46 PM, The Real Bev wrote:
> On 10/18/2016 04:05 PM, T wrote:
>> On 10/18/2016 01:59 AM, William Unruh wrote:
>>> On 2016-10-18, T <T@invalid.invalid> wrote:
>>>> Hi All,
>>>>
>>>> How do you read a pipe with a bash script?
>>>>
>>>> Many thanks, -T
>>>>
>>>> This does not work
>>>>
>>>> echo 123 | eraseme2.sh
>>>
>>> Sure it does.
>>
>> That is clearly not what I meant.
>>
>>> You just did not write the script properly to read from stdin if no
>>> filename is given.
>>>>
>>>> $ more eraseme2.sh #!/bin/bash echo $1
>>>
>>> stdin s NOT $1. You have no first argument. You have to tell the
>>> script that if there is no first arbument, to read from stdin.
>>
>> I wonder why everyone are so grumpy today?
>
> Well, we spent a lot of time fixing the toilet today...
>

Well, it is not like I am never crabby.  I just noticed
a lot of folks crabby today on a couple of groups.
Maybe there is a cold going around.

T <T@invalid.invalid> wrote:
> On 10/18/2016 07:59 PM, Rich wrote:
>> T <T@invalid.invalid> wrote:
>>> What would I do to the above to transfer the data to a variable?
>>
>> The above already transfers the data to a variable.  $1, $2, $3, $4,
>> etc.  (the positional parameters, which are just variables to the
>> script), get set to each word in the data sent over the pipe.
>>
>> But as you've not yet told us specifically what you are trying to
>> do, the above _may_ not be what you are looking to accomplish.
> 
> Well, originally I was doing something with Lotus Script that
> involved a system call (Lotus script called is "Shell") to a bash
> script that used a pipe, then changed my mind.

Ok, but did Lotus Script try to pipe data to the Bash script, or did
the Bash script use a pipe internally?

> From there I realized I need to know how to do this for future
> reference.  So what I am after is what I call a "Keeper" (a.k.a.  How
> To) file that explains the process.  Your explanation on the set
> command and -- will be in it.
> 
> To get Keeper finalized, I want to make a sample script that shows
> the process.
> 
> In common language (not bash), this is what I want from the script is
> 
> if a command line parameter(s) exist, write the(m) out and where
> it/they came from (from parameters on the command line)

In Bash that would be done by checking the $# variable.  If it is zero,
then there were not command line parameters.

> else if a pipe existed, write it out and where it came from (from a
> pipe)

Do you mean:
  1) write out that a pipe was connected?
  or
  2) write out the data being transmitted over the pipe?

Because if you mean #1, that fact is likely detectable from a C
program, but I am not sure if Bash has a way to detect that a pipe was
connected.  

If you mean #2, then unless the data flowing over the pipe is small,
the set -- $(cat) method will quickly fail.  If you want to read the
pipe directly in Bash (as opposed to letting another command read
stdin), you'll most likely want to use the 'read' command and a while
loop:

  while read data ; do echo data=$data ; done

The 'read' command also has multiple options that change how it
operates, read the manpage for the details.

> else if neither existed, state such (no hanging waiting
> for something that is not there -- very important)

Unless there is a way in Bash to detect that stdin is a terminal vs.
not a terminal, then there is no way (save possibly writing a C helper)
for Bash to not hang.  Because when Bash starts, it simply sees stdin,
and can try reading therefrom.  But if stdin is a terminal (which it
will be when there is no pipe connected) the read will wait for a user
to type something or send an EOF (control+d) over the terminal.

T <T@invalid.invalid> wrote:
> On 10/18/2016 09:46 PM, The Real Bev wrote:
>> On 10/18/2016 04:05 PM, T wrote:
>>> I wonder why everyone are so grumpy today?
>>
>> Well, we spent a lot of time fixing the toilet today...
> 
> Well, it is not like I am never crabby.  I just noticed a lot of
> folks crabby today on a couple of groups.  Maybe there is a cold
> going around.

Note that asking vague questions has a tendancy to cause grumpiness and
crabbiness in long time group members.  Reason being that someone
spends multiple back-and-forth cycles of trying to answer only to find
the goal-posts moved each time.  This tends to wear on most folks
patience, esp. as it is a *very* common occurrence on Usenet.

If instead the question began with the details that take six
back-and-forth replies to get, usually the right answer could be
provided quickly, rather than multiple wrong answers and necessary
attempts to try again, only to find that no, that answer's not for the
real question.

* Rich <rich@example.invalid>
| Unless there is a way in Bash to detect that stdin is a terminal vs.
| not a terminal,

That would be

  test -t 0

  $ bash -c "if test -t 0 ; then echo terminal ; else echo no terminal ; fi"
  terminal
  
  $ bash -c "if test -t 0 ; then echo terminal ; else echo no terminal ; fi" < /dev/null
  no terminal

R'

On 19.10.16 12:10, T wrote:

> If you think Perl is a write only language, I suggest if
> you ever come across Lotus Script that you RUN LIKE HELL!

There are plenty of them: My candidate is Forth.

-- 

-TV

On 19/10/16 13:14, Tauno Voipio wrote:
> On 19.10.16 12:10, T wrote:
>
>> If you think Perl is a write only language, I suggest if
>> you ever come across Lotus Script that you RUN LIKE HELL!
>
> There are plenty of them: My candidate is Forth.
>
I like Forth. Cant write it worth a damn, but I admire its chutzpah.


-- 
Ideas are more powerful than guns. We would not let our enemies have 
guns, why should we let them have ideas?

Josef Stalin

On Wed, 19 Oct 2016 02:10:04 -0700, T wrote:
> To get Keeper finalized, I want to make a sample script that
> shows the process.
> 
> In common language (not bash), this is what I want from
> the script is
> 
> if a command line parameter(s) exist, write the(m) out and
> where it/they came from (from parameters on the command line)
> 
> else if a pipe existed, write it out and where it came from
> (from a pipe)
> 
> else if neither existed, state such (no hanging waiting
> for something that is not there -- very important)

Interesting. Had to write it...

#!/bin/bash
if [ -n "$*" ];then			# has something on command line
	echo "command line: $*"		# print it plain
	for arg in "$@";do		# iterate over quoted command line args
		echo "arg: '$arg'"	# print the arg
	done
elif [ -t 0 ] ;then			# stdout is a tty
	echo "No command and no stdin!"	# tell em
	exit 1				# exit with error status
else
	if ! read -t 0 ;then		# there is no input ready
		sleep .5		# give lhs of pipe time to start
	fi
	if read -t 0 ;then		# there is input ready
		echo "stdin:"		# tell where it came from
		cat			# copy stdin to stdout
	fi
fi

Note that the right side of a pipeline is generally started first. So
   ls|keeper
will run keeper before ls. Depending on timing ls might not have been
able to output anything by the time keeper gets to it's "read -t 0".
So I added a small delay to give it a chance. Still no guarantee if
the lhs of the pipe takes a while to start outputting.

A better convention would be to accept a single "-" command line arg to
mean read stdin so the intent is specific and there's no waiting/guessing.

#!/bin/bash
if [ "$*" = "-" ];then			# command line is exactly "-"
	echo "stdin:"			# tell where it came from
	cat				# copy stdin to stdout
elif [ -n "$*" ];then			# has something on command line
	echo "command line: $*"		# print it plain
	for arg in "$@";do		# iterate over quoted command line args
		echo "arg: '$arg'"	# print the arg
	done
else
	echo "Nothing to do!"		# tell em
	exit 1				# exit with error status
fi

In article <nu7ko9$i6q$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
....
>  2) write out the data being transmitted over the pipe?
>
>Because if you mean #1, that fact is likely detectable from a C
>program, but I am not sure if Bash has a way to detect that a pipe was
>connected.  

As another posted stated, it is possible to detect if it is a terminal
device or not.  This is not quite the same as knowing whether or not it is
a pipe, but, in practice, this is usually good enough.  Generally, when
people ask this question, what they really mean is "Is it a terminal?" -
anything else (and there are several possibilities, including a pipe, a
file, a socket, etc) is assumed to be the same (i.e., is treated the same
by the program/programmer).

The usual bash idiom is:

    [ -t 0 ] || echo "Not a terminal!"

Now, just for grins, if you are running Linux (a safe assumption given the
group to which this is posted), then you can do tricks with /proc and
figure out exactly what type of thing fd 0 is connected to.  I wrote the
following script:

--- Cut Here ---
#!/bin/bash
ls -lsa /proc/self/fd/0
--- Cut Here ---

Put that in a file, make it executable, and try running it with various
redirections, e.g.,:

    yourfile
    yourfile < /dev/null
    echo foo | yourfile

Work out from there how you could write a script to detect specifically if
standard input is a pipe.

>If you mean #2, then unless the data flowing over the pipe is small,
>the set -- $(cat) method will quickly fail.

Granted, although the definition of "not small" might be surprising.
Remember, this is Linux we're talking about here, not some rinky dink
antedeluvian Unix.

Anyway, it is pretty clear from the general context of this thread that the
data size is going to be not only small, but "very small".

....

>Unless there is a way in Bash to detect that stdin is a terminal vs.
>not a terminal, then there is no way (save possibly writing a C helper)
>for Bash to not hang.

Actually, the bash implementation of "read" does have timelimit/timeout
functionality, so you could set it up to not hang when stdin is a terminal
(and no one is there to enter anything).

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain in
compliance with said RFCs, the actual sig can be found at the following web address:
	http://www.xmission.com/~gazelle/Sigs/IceCream

On 10/19/2016 05:43 AM, The Natural Philosopher wrote:
> On 19/10/16 13:14, Tauno Voipio wrote:
>> On 19.10.16 12:10, T wrote:
>>
>>> If you think Perl is a write only language, I suggest if
>>> you ever come across Lotus Script that you RUN LIKE HELL!
>>
>> There are plenty of them: My candidate is Forth.
>>
> I like Forth. Cant write it worth a damn, but I admire its chutzpah.
>
>
	On the Amiga we had, and possibly still can have, Textra a very
capable text processor written in Forth.  It was shareware, As a result
I spent some time studying FORTH which was the fourth of a series of
languages.  It was called FORTH because when it was developed the
OS of the time could only handle 5 characters + an 3 character
extension or maybe that came later.  It was extensible if you could
program in it.

	bliss

-- 
bliss dash SF 4 ever at dslextreme dot com

On 2016-10-19, The Natural Philosopher <tnp@invalid.invalid> wrote:

> On 19/10/16 13:14, Tauno Voipio wrote:
>
>> On 19.10.16 12:10, T wrote:
>>
>>> If you think Perl is a write only language, I suggest if
>>> you ever come across Lotus Script that you RUN LIKE HELL!
>>
>> There are plenty of them: My candidate is Forth.
>
> I like Forth. Cant write it worth a damn, but I admire its chutzpah.

Forth love if honk then

-- 
/~\  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!

Bobbie Sellers <bliss@mouse-potato.com> wrote:
> On 10/19/2016 05:43 AM, The Natural Philosopher wrote:
>> On 19/10/16 13:14, Tauno Voipio wrote:
>>> On 19.10.16 12:10, T wrote:
>>>
>>>> If you think Perl is a write only language, I suggest if
>>>> you ever come across Lotus Script that you RUN LIKE HELL!
>>>
>>> There are plenty of them: My candidate is Forth.
>>>
>> I like Forth. Cant write it worth a damn, but I admire its chutzpah.
>>
>>
> 	On the Amiga we had, and possibly still can have, Textra a very
> capable text processor written in Forth.  It was shareware, As a result
> I spent some time studying FORTH which was the fourth of a series of
> languages.  It was called FORTH because when it was developed the
> OS of the time could only handle 5 characters + an 3 character
> extension or maybe that came later.  It was extensible if you could
> program in it.
>
> 	bliss
>

If you used the older HP calculators you will be able to think in forth.

Ralf Fassel <ralfixx@gmx.de> wrote:
> * Rich <rich@example.invalid>
> | Unless there is a way in Bash to detect that stdin is a terminal vs.
> | not a terminal,
> 
> That would be
> 
>  test -t 0
> 
>  $ bash -c "if test -t 0 ; then echo terminal ; else echo no terminal ; fi"
>  terminal
>  
>  $ bash -c "if test -t 0 ; then echo terminal ; else echo no terminal ; fi" < /dev/null
>  no terminal

So it is possible.  Thank you.  I learned something new just now.

On 10/19/2016 04:17 AM, Rich wrote:
> T <T@invalid.invalid> wrote:
>> On 10/18/2016 07:59 PM, Rich wrote:
>>> T <T@invalid.invalid> wrote:
>>>> What would I do to the above to transfer the data to a variable?
>>>
>>> The above already transfers the data to a variable.  $1, $2, $3, $4,
>>> etc.  (the positional parameters, which are just variables to the
>>> script), get set to each word in the data sent over the pipe.
>>>
>>> But as you've not yet told us specifically what you are trying to
>>> do, the above _may_ not be what you are looking to accomplish.
>>
>> Well, originally I was doing something with Lotus Script that
>> involved a system call (Lotus script called is "Shell") to a bash
>> script that used a pipe, then changed my mind.
>
> Ok, but did Lotus Script try to pipe data to the Bash script, or did
> the Bash script use a pipe internally?

Lotus Script send what to the system whatever is in the quotes.
I was thinking of sending a pipe inside the quotes, but abandoned
the whole idea.

>
>> From there I realized I need to know how to do this for future
>> reference.  So what I am after is what I call a "Keeper" (a.k.a.  How
>> To) file that explains the process.  Your explanation on the set
>> command and -- will be in it.
>>
>> To get Keeper finalized, I want to make a sample script that shows
>> the process.
>>
>> In common language (not bash), this is what I want from the script is
>>
>> if a command line parameter(s) exist, write the(m) out and where
>> it/they came from (from parameters on the command line)
>
> In Bash that would be done by checking the $# variable.  If it is zero,
> then there were not command line parameters.
>
>> else if a pipe existed, write it out and where it came from (from a
>> pipe)
>
> Do you mean:
>   1) write out that a pipe was connected?
>   or
>   2) write out the data being transmitted over the pipe?

Both.  The example is to demonstrate the concept.


>
> Because if you mean #1, that fact is likely detectable from a C
> program, but I am not sure if Bash has a way to detect that a pipe was
> connected.
>
> If you mean #2, then unless the data flowing over the pipe is small,
> the set -- $(cat) method will quickly fail.  If you want to read the
> pipe directly in Bash (as opposed to letting another command read
> stdin), you'll most likely want to use the 'read' command and a while
> loop:
>
>   while read data ; do echo data=$data ; done
>
> The 'read' command also has multiple options that change how it
> operates, read the manpage for the details.
>
>> else if neither existed, state such (no hanging waiting
>> for something that is not there -- very important)
>
> Unless there is a way in Bash to detect that stdin is a terminal vs.
> not a terminal, then there is no way (save possibly writing a C helper)
> for Bash to not hang.  Because when Bash starts, it simply sees stdin,
> and can try reading therefrom.  But if stdin is a terminal (which it
> will be when there is no pipe connected) the read will wait for a user
> to type something or send an EOF (control+d) over the terminal.


Hmmm. Things to think about.  I should probably show how to
stick the pipe into variables and how to read it a a long string.

I have written perl code to see if anything is in the read
buffer, but that would defeat the purpose of a bash example.

Thank you for the help!

-T

On 10/19/2016 04:21 AM, Rich wrote:
> T <T@invalid.invalid> wrote:
>> On 10/18/2016 09:46 PM, The Real Bev wrote:
>>> On 10/18/2016 04:05 PM, T wrote:
>>>> I wonder why everyone are so grumpy today?
>>>
>>> Well, we spent a lot of time fixing the toilet today...
>>
>> Well, it is not like I am never crabby.  I just noticed a lot of
>> folks crabby today on a couple of groups.  Maybe there is a cold
>> going around.
>
> Note that asking vague questions has a tendancy to cause grumpiness and
> crabbiness in long time group members.  Reason being that someone
> spends multiple back-and-forth cycles of trying to answer only to find
> the goal-posts moved each time.  This tends to wear on most folks
> patience, esp. as it is a *very* common occurrence on Usenet.
>
> If instead the question began with the details that take six
> back-and-forth replies to get, usually the right answer could be
> provided quickly, rather than multiple wrong answers and necessary
> attempts to try again, only to find that no, that answer's not for the
> real question.
>
>

Hmmmm.  "How do you read a pipe with a bash script?"  I do
not see where that is "vague" at all.  Seems to me I got
straight to the point.  I think something is going around.
Hay fever tends to make me crabby.  Or it could be
a cold.

T <T@invalid.invalid> wrote:
> On 10/19/2016 04:21 AM, Rich wrote:
>> T <T@invalid.invalid> wrote:
>>> On 10/18/2016 09:46 PM, The Real Bev wrote:
>>>> On 10/18/2016 04:05 PM, T wrote:
>>>>> I wonder why everyone are so grumpy today?
>>>>
>>>> Well, we spent a lot of time fixing the toilet today...
>>>
>>> Well, it is not like I am never crabby.  I just noticed a lot of
>>> folks crabby today on a couple of groups.  Maybe there is a cold
>>> going around.
>>
>> Note that asking vague questions has a tendancy to cause grumpiness and
>> crabbiness in long time group members.  Reason being that someone
>> spends multiple back-and-forth cycles of trying to answer only to find
>> the goal-posts moved each time.  This tends to wear on most folks
>> patience, esp. as it is a *very* common occurrence on Usenet.
>>
>> If instead the question began with the details that take six
>> back-and-forth replies to get, usually the right answer could be
>> provided quickly, rather than multiple wrong answers and necessary
>> attempts to try again, only to find that no, that answer's not for the
>> real question.
>>
>>
> 
> Hmmmm.  "How do you read a pipe with a bash script?"  I do
> not see where that is "vague" at all.

As you have seen in this thread, there are multiple different ways to
"read a pipe" in bash.  That is what makes the question vague.  Not to
mention that there are two different kinds of pipes, and how one would
"read" each in a bash script differs yet again.

> Seems to me I got straight to the point.

No, not really.  Getting "straight to the point" would have been
something like:

  I have a Lotus script application that launches a bash script with
  the bash script's standard input connected to a pipe from the Lotus
  script.  How do I read the data being passed over the pipe from Lotus
  script inside the bash script?

In article <nubnic$qgf$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>Not to
>mention that there are two different kinds of pipes, and how one would
>"read" each in a bash script differs yet again.

In what sense are there two kinds of pipes?

-- 
b w r w g y b r y b

At Fri, 21 Oct 2016 00:46:19 +0000 (UTC) gazelle@shell.xmission.com (Kenny McCormack) wrote:

> 
> In article <nubnic$qgf$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
> >Not to
> >mention that there are two different kinds of pipes, and how one would
> >"read" each in a bash script differs yet again.
> 
> In what sense are there two kinds of pipes?

Named and unnamed pipes. Not really different in terms of actually reading
them (read works for either), other than how one might "connect" to one or the
other or how they might be created.

> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                            

In article <vq-dnfvPXYaP8ZTFnZ2dnUU7-KPNnZ2d@giganews.com>,
Robert Heller  <heller@deepsoft.com> wrote:
>At Fri, 21 Oct 2016 00:46:19 +0000 (UTC) gazelle@shell.xmission.com (Kenny
>McCormack) wrote:
>
>> 
>> In article <nubnic$qgf$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>> >Not to
>> >mention that there are two different kinds of pipes, and how one would
>> >"read" each in a bash script differs yet again.
>> 
>> In what sense are there two kinds of pipes?
>
>Named and unnamed pipes. Not really different in terms of actually reading
>them (read works for either), other than how one might "connect" to one or the
>other or how they might be created.

OK.  Point taken.

-- 
I've been watching cat videos on YouTube.  More content and closer to
the truth than anything on Fox.

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <nubnic$qgf$1@dont-email.me>, Rich  <rich@example.invalid> wrote:
>>Not to
>>mention that there are two different kinds of pipes, and how one would
>>"read" each in a bash script differs yet again.
> 
> In what sense are there two kinds of pipes?

Named and anonymous pipes.

On 10/20/2016 05:30 PM, Rich wrote:
> T <T@invalid.invalid> wrote:
>> On 10/19/2016 04:21 AM, Rich wrote:
>>> T <T@invalid.invalid> wrote:
>>>> On 10/18/2016 09:46 PM, The Real Bev wrote:
>>>>> On 10/18/2016 04:05 PM, T wrote:
>>>>>> I wonder why everyone are so grumpy today?
>>>>>
>>>>> Well, we spent a lot of time fixing the toilet today...
>>>>
>>>> Well, it is not like I am never crabby.  I just noticed a lot of
>>>> folks crabby today on a couple of groups.  Maybe there is a cold
>>>> going around.
>>>
>>> Note that asking vague questions has a tendancy to cause grumpiness and
>>> crabbiness in long time group members.  Reason being that someone
>>> spends multiple back-and-forth cycles of trying to answer only to find
>>> the goal-posts moved each time.  This tends to wear on most folks
>>> patience, esp. as it is a *very* common occurrence on Usenet.
>>>
>>> If instead the question began with the details that take six
>>> back-and-forth replies to get, usually the right answer could be
>>> provided quickly, rather than multiple wrong answers and necessary
>>> attempts to try again, only to find that no, that answer's not for the
>>> real question.
>>>
>>>
>>
>> Hmmmm.  "How do you read a pipe with a bash script?"  I do
>> not see where that is "vague" at all.
>
> As you have seen in this thread, there are multiple different ways to
> "read a pipe" in bash.  That is what makes the question vague.  Not to
> mention that there are two different kinds of pipes, and how one would
> "read" each in a bash script differs yet again.
>
>> Seems to me I got straight to the point.
>
> No, not really.  Getting "straight to the point" would have been
> something like:
>
>   I have a Lotus script application that launches a bash script with
>   the bash script's standard input connected to a pipe from the Lotus
>   script.  How do I read the data being passed over the pipe from Lotus
>   script inside the bash script?
>

That explains it.

      "Well, originally I was doing something with Lotus Script
      that involved a system call (Lotus script called is "Shell")
      to a bash script that used a pipe, then changed my mind.

      From there I realized I need to know how to do this
      for future reference.  So what I am after is what I
      call a "Keeper" (a.k.a. How To) file that explains the
      process."

You thought I was need to know how to do this with Lotus Script.
I am after how to read a pipe sent to a bash script.

-T

On 2016-10-25, T <T@invalid.invalid> wrote:
> On 10/20/2016 05:30 PM, Rich wrote:
>> T <T@invalid.invalid> wrote:
>>> On 10/19/2016 04:21 AM, Rich wrote:
>>>> T <T@invalid.invalid> wrote:
>>>>> On 10/18/2016 09:46 PM, The Real Bev wrote:
>>>>>> On 10/18/2016 04:05 PM, T wrote:
>>>>>>> I wonder why everyone are so grumpy today?
>>>>>>
>>>>>> Well, we spent a lot of time fixing the toilet today...
>>>>>
>>>>> Well, it is not like I am never crabby.  I just noticed a lot of
>>>>> folks crabby today on a couple of groups.  Maybe there is a cold
>>>>> going around.
>>>>
>>>> Note that asking vague questions has a tendancy to cause grumpiness and
>>>> crabbiness in long time group members.  Reason being that someone
>>>> spends multiple back-and-forth cycles of trying to answer only to find
>>>> the goal-posts moved each time.  This tends to wear on most folks
>>>> patience, esp. as it is a *very* common occurrence on Usenet.
>>>>
>>>> If instead the question began with the details that take six
>>>> back-and-forth replies to get, usually the right answer could be
>>>> provided quickly, rather than multiple wrong answers and necessary
>>>> attempts to try again, only to find that no, that answer's not for the
>>>> real question.
>>>>
>>>>
>>>
>>> Hmmmm.  "How do you read a pipe with a bash script?"  I do
>>> not see where that is "vague" at all.
>>
>> As you have seen in this thread, there are multiple different ways to
>> "read a pipe" in bash.  That is what makes the question vague.  Not to
>> mention that there are two different kinds of pipes, and how one would
>> "read" each in a bash script differs yet again.
>>
>>> Seems to me I got straight to the point.
>>
>> No, not really.  Getting "straight to the point" would have been
>> something like:
>>
>>   I have a Lotus script application that launches a bash script with
>>   the bash script's standard input connected to a pipe from the Lotus
>>   script.  How do I read the data being passed over the pipe from Lotus
>>   script inside the bash script?
>>
>
> That explains it.
>
>       "Well, originally I was doing something with Lotus Script
>       that involved a system call (Lotus script called is "Shell")
>       to a bash script that used a pipe, then changed my mind.
>
>       From there I realized I need to know how to do this
>       for future reference.  So what I am after is what I
>       call a "Keeper" (a.k.a. How To) file that explains the
>       process."
>
> You thought I was need to know how to do this with Lotus Script.
> I am after how to read a pipe sent to a bash script.

So the answer is, with a program in the bash script that reads from
stdin. 
>
> -T