Re: Bash question hard to formulate

[David Wright]

On Mon 03 Aug 2020 at 11:30:42 (+0200), Esteban L wrote:

> I am not typing return. I am typing in a sentence...As I receive new
> output to the terminal window, and I continue typing, my text stream
> just goes down a line. Which is fine, UNLESS I otherwise want to correct
> something, and backspacing doesn't word wrap back to the previously
> typed line.

If characters are typed by a process while you're typing a command
line, then naively trying to backspace over a newline will not work
because bash has a different idea of where the cursor is from reality.

If you just ignore said characters, the command line you typed will
be unaffected, and will execute correctly when you press Return.

> the main thing I want is, if I backspace into a sentence (as I am
> receiving output to the terminal window and that i have not CR'ed), that
> the incomplete sentence will re-show up on the active line, when I reach
> the beginning of the that line.

That's not going to work. When you "backspace into a sentence", you're
rubbing out characters that *you* typed, even though the characters
that are actually disappearing from the display are the ones that were
displayed last, ie those output by the other process.

If you want the characters that *you* typed to be re-shown, clean, on
the command line, then pressing Ctrl-L is the correct way to do it.
*Then* apply your corrections, using Backspace or the arrow keys as
appropriate.

Cheers,
David.

Re: Bash question hard to formulate

[songbird]

 wrote:
> On Mon, Aug 03, 2020 at 12:47:32AM -0400, songbird wrote:
>> ...
>>=20
>>   i'm not familiar with that problem but another tip
>> which is helpful when dealing with a terminal that
>> gets into a strange state is to press return then
>> type in reset and press return again.
>
> Typing return when you have already half-a-command line
> (and are not sure what it is) is somewhat dangerous.
>
> That's OK, it can be a life style. Be sure to keep some
> backups around, then :-)

  haha, yeah...  with github these days my more recent
projects are being backed up "off site" so i'm not too
worried about the most recent changes not being 
available to me in case of a severe crash.  but i do
also keep backups.

  Ctrl-C can also be used to cancel a command in progress.
:)  i'm not often typing dangerous commands into the 
terminal, especially one which is in an odd state.


  songbird

Re: Bash question hard to formulate

[Esteban L]

I think that is the main thing.

I am not typing return. I am typing in a sentence...As I receive new
output to the terminal window, and I continue typing, my text stream
just goes down a line. Which is fine, UNLESS I otherwise want to correct
something, and backspacing doesn't word wrap back to the previously
typed line.

Had trouble sleeping =) trying to figure it out.

I don't know if it's Bash related, inputrc, terminal, debian, or whatever.

I was reading that perhaps setting the "auto left margin" to ON, would
allow the cursor to wordwrap (in reverse) to the previous line.

I have thought about using a different terminal window, but so far they
all seem to exhibit the same behavior. I thought gnome-terminal was
bloated, and had extra features compared to other sleeker versions - but
alas, it also exhibits this behavior.

Though, I admit, i am almost at my wits end.

I assume everyone has this behavior from Debian? I only have default
settings, on two boxes (Debian 9, and Debian 10), and the behavior is
the same on both. EPP! I just realized, I have 4 Debians =D The behavior
is the same on all of them.

the main thing I want is, if I backspace into a sentence (as I am
receiving output to the terminal window and that i have not CR'ed), that
the incomplete sentence will re-show up on the active line, when I reach
the beginning of the that line.

I think this is one of those classic examples of "it's easy if you know
how" =) But, if you don't, it's as hard as humanly possible.


On 8/3/20 10:12 AM, to...@tuxteam.de wrote:
> On Mon, Aug 03, 2020 at 12:47:32AM -0400, songbird wrote:
>> ...
>>
>>   i'm not familiar with that problem but another tip
>> which is helpful when dealing with a terminal that
>> gets into a strange state is to press return then
>> type in reset and press return again.
> Typing return when you have already half-a-command line
> (and are not sure what it is) is somewhat dangerous.
>
> That's OK, it can be a life style. Be sure to keep some
> backups around, then :-)
>
> Cheers
> -- t



signature.asc
Description: OpenPGP digital signature

Re: Bash question hard to formulate

[tomas]

On Mon, Aug 03, 2020 at 12:47:32AM -0400, songbird wrote:
> ...
> 
>   i'm not familiar with that problem but another tip
> which is helpful when dealing with a terminal that
> gets into a strange state is to press return then
> type in reset and press return again.

Typing return when you have already half-a-command line
(and are not sure what it is) is somewhat dangerous.

That's OK, it can be a life style. Be sure to keep some
backups around, then :-)

Cheers
-- t


signature.asc
Description: Digital signature

Re: Bash question hard to formulate

[songbird]

...

  i'm not familiar with that problem but another tip
which is helpful when dealing with a terminal that
gets into a strange state is to press return then
type in reset and press return again.


  songbird

Re: Bash question hard to formulate

[David Wright]

On Sun 02 Aug 2020 at 17:34:07 (+0200), Esteban L wrote:
> 
> I use terminal window/bash quite a bit, and have a quirky behavior on
> Debian, at least not on Mac OS terminal window. I think it's just a
> default issue, that can be altered -- as I had the exact same problem
> years ago -- that I was able to resolve, which I again turns up. I
> forgot the solution, since it was so simple.
> 
> The question is hard for me to formulate, so I will just describe
> everything, and maybe someone can help?
> 
> What happens:
> 
> I use terminal (in a game or even with ping for simplicity):
> 
> I can type into the terminal.
> 
> I can backspace - as expected.
> 
> However, if i receive new data - my typed text is still in the buffer,
> but is not "echo'd" to a new line. This is more or less OK, UNLESS I
> need to backspace and clear some text. I just can't tell how far I have
> backspaced, since the line is not echoed.
> 
> Maybe best description is:
> 
> I am tying this senten
> 
> 
> 
> ce, and it's fine...but i
> 
> 
> 
> I backspace now, as I want to replace the above line "and it's fine" and
> what comes after it to change it to "it's not fine"
> 
> So, best description is, if i backspace upon receiving new data, I
> cannot see the line that I was typing.
> 
> Any Bash experts able to lend a hand?
> 
> Last time I had this issue, I remember I had to go into .bashrc and
> add/change something. I just don't know what it was.

Is it possible you've been using some facility like that described in
https://www.gnu.org/software/screen/manual/html_node/Flow-Control.html#Flow-Control

Cheers,
David.

Re: Bash question hard to formulate

[Esteban L]

Thanks for the tip Andrei!

I am not 100% sure it was .bashrc, it could have been some other config
file, but I am pretty sure it was bash related. it is unfortunately on a
long since gone system.

As to my current system, I have just default settings. I have not
altered anything. I have only tried changing terminal preferences to
getting the desire result.

It's weird. Because on macOS which I don't really want to use, it works
fine. Easy test case is:

launch terminal, ping 8.8.8.8.

In macOS, the current line will just repopulate itself when i hit backspace.

In debian (xterm or terminal), pinging 8.8.8.8, and just putting in
random text does not repopulate on the line i am working on, when i hit
backspace.

I will keep searching for a solution, and send it to the list when I
find it.


On 02.08.20 20:26, Andrei POPESCU wrote:
> On Du, 02 aug 20, 17:34:07, Esteban L wrote:
>> Last time I had this issue, I remember I had to go into .bashrc and
>> add/change something. I just don't know what it was.
> Could it be you changed .inputrc and not .bashrc?
>
> Kind regards,
> Andrei

-- 
https://www.little-beak.com
"Doing what we can."




signature.asc
Description: OpenPGP digital signature

Re: Bash question hard to formulate

[Andrei POPESCU]

On Du, 02 aug 20, 17:34:07, Esteban L wrote:
> 
> Last time I had this issue, I remember I had to go into .bashrc and
> add/change something. I just don't know what it was.

Could it be you changed .inputrc and not .bashrc?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Bash question hard to formulate

[Esteban L]

Ah now that I analyze the behavior on a MacOS, I see the thing is this:

If I am typing text in, and receive new text, the cursor continues
typing. UNLESS I backspace to the beginning of the (current) line, and
then it echos the previously typed text.

Thanks for the tip! I will try that out.

But, I did solve this at one point in the past, with a bash profile
change, so I know that is possible.

On 02.08.20 17:49, The Wanderer wrote:
> On 2020-08-02 at 11:34, Esteban L wrote:
>
>> Hello,
>>
>> I use terminal window/bash quite a bit, and have a quirky behavior
>> on Debian, at least not on Mac OS terminal window. I think it's just
>> a default issue, that can be altered -- as I had the exact same
>> problem years ago -- that I was able to resolve, which I again turns
>> up. I forgot the solution, since it was so simple.
>>
>> The question is hard for me to formulate, so I will just describe
>> everything, and maybe someone can help?
>>
>> What happens:
>>
>> I use terminal (in a game or even with ping for simplicity):
>>
>> I can type into the terminal.
>>
>> I can backspace - as expected.
>>
>> However, if i receive new data - my typed text is still in the
>> buffer, but is not "echo'd" to a new line. This is more or less OK,
>> UNLESS I need to backspace and clear some text. I just can't tell how
>> far I have backspaced, since the line is not echoed.
>>
>> Maybe best description is:
>>
>> I am tying this senten
>>
>> 
>>
>> ce, and it's fine...but i
>>
>> 
>>
>> I backspace now, as I want to replace the above line "and it's fine"
>> and what comes after it to change it to "it's not fine"
>>
>>
>> So, best description is, if i backspace upon receiving new data, I
>> cannot see the line that I was typing.
> This is a manifestation of the longstanding scenario of "terminal output
> steps all over the shell prompt", and related.
>
> What I usually do, in similar circumstances, is to press first the Up
> arrow and then the Down arrow.
>
> This goes one level up into shell history, so that bash removes the
> currently-displayed in-progress command and displays the
> previously-entered one, and then one level back down, so that bash
> removes the currently-displayed previously-entered command and displays
> the one still in progress.
>
> Not necessarily the best solution, but it usually gets the job done,
> assuming your environment supports this type of history functionality in
> the first place.
>
>> Any Bash experts able to lend a hand?
>>
>> Last time I had this issue, I remember I had to go into .bashrc and 
>> add/change something. I just don't know what it was.
> I have no idea what it could be either. By my understanding of the
> nature of the problem and what leads it to occur, I don't see how any
> bash configuration could possibly avoid it.
>
-- 
https://www.little-beak.com
"Doing what we can."




signature.asc
Description: OpenPGP digital signature

Re: Bash question hard to formulate

[tomas]

On Sun, Aug 02, 2020 at 05:34:07PM +0200, Esteban L wrote:
> Hello,

[...]

> Maybe best description is:
> 
> I am tying this senten
> 
> 
> 
> ce, and it's fine...but i
> 
> 
> 
> I backspace now, as I want to replace the above line "and it's fine" and
> what comes after it to change it to "it's not fine"
> 
> 
> So, best description is, if i backspace upon receiving new data, I
> cannot see the line that I was typing.

Apart from The Wanderer's good suggestion, there's always CTRL-L, which
redisplays the typed-line-so-far clearing out everything else (this may
be desired or not).

This will work in other (terminal-ish) contexts, like vi(m) or more/less,
cleaning up when the terminal and the program behind it get confused.

Cheers
-- t


signature.asc
Description: Digital signature

Re: Bash question hard to formulate

[The Wanderer]

On 2020-08-02 at 11:34, Esteban L wrote:

> Hello,
> 
> I use terminal window/bash quite a bit, and have a quirky behavior
> on Debian, at least not on Mac OS terminal window. I think it's just
> a default issue, that can be altered -- as I had the exact same
> problem years ago -- that I was able to resolve, which I again turns
> up. I forgot the solution, since it was so simple.
> 
> The question is hard for me to formulate, so I will just describe
> everything, and maybe someone can help?
> 
> What happens:
> 
> I use terminal (in a game or even with ping for simplicity):
> 
> I can type into the terminal.
> 
> I can backspace - as expected.
> 
> However, if i receive new data - my typed text is still in the
> buffer, but is not "echo'd" to a new line. This is more or less OK,
> UNLESS I need to backspace and clear some text. I just can't tell how
> far I have backspaced, since the line is not echoed.
> 
> Maybe best description is:
> 
> I am tying this senten
> 
> 
> 
> ce, and it's fine...but i
> 
> 
> 
> I backspace now, as I want to replace the above line "and it's fine"
> and what comes after it to change it to "it's not fine"
> 
> 
> So, best description is, if i backspace upon receiving new data, I
> cannot see the line that I was typing.

This is a manifestation of the longstanding scenario of "terminal output
steps all over the shell prompt", and related.

What I usually do, in similar circumstances, is to press first the Up
arrow and then the Down arrow.

This goes one level up into shell history, so that bash removes the
currently-displayed in-progress command and displays the
previously-entered one, and then one level back down, so that bash
removes the currently-displayed previously-entered command and displays
the one still in progress.

Not necessarily the best solution, but it usually gets the job done,
assuming your environment supports this type of history functionality in
the first place.

> Any Bash experts able to lend a hand?
> 
> Last time I had this issue, I remember I had to go into .bashrc and 
> add/change something. I just don't know what it was.

I have no idea what it could be either. By my understanding of the
nature of the problem and what leads it to occur, I don't see how any
bash configuration could possibly avoid it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bash question hard to formulate

[Esteban L]

Hello,

I use terminal window/bash quite a bit, and have a quirky behavior on
Debian, at least not on Mac OS terminal window. I think it's just a
default issue, that can be altered -- as I had the exact same problem
years ago -- that I was able to resolve, which I again turns up. I
forgot the solution, since it was so simple.

The question is hard for me to formulate, so I will just describe
everything, and maybe someone can help?

What happens:

I use terminal (in a game or even with ping for simplicity):

I can type into the terminal.

I can backspace - as expected.

However, if i receive new data - my typed text is still in the buffer,
but is not "echo'd" to a new line. This is more or less OK, UNLESS I
need to backspace and clear some text. I just can't tell how far I have
backspaced, since the line is not echoed.

Maybe best description is:

I am tying this senten



ce, and it's fine...but i



I backspace now, as I want to replace the above line "and it's fine" and
what comes after it to change it to "it's not fine"


So, best description is, if i backspace upon receiving new data, I
cannot see the line that I was typing.


Any Bash experts able to lend a hand?

Last time I had this issue, I remember I had to go into .bashrc and
add/change something. I just don't know what it was.


Thanks.

Re: Bash Question

[Greg Wooledge]

On Thu, Jul 06, 2017 at 05:25:05PM +1000, David wrote:
> Shells do not set this variable to identify themselves.

> On jessie, 'man 1 login', states that it sets SHELL. I understand this to
> mean that 'login' exports SHELL as an environment variable to child
> processes of 'login'.
> 
> I believe 'login' sets SHELL to the value of the user's login shell, as read
> from /etc/passwd. Once. And after that it does not change.

Yes, this is correct.  The SHELL variable is used by programs like vi
that have a "shell escape" feature, so that they know which shell to
execute.  (And also X terminal emulators, etc.)  It's what shell you
*want*, not what shell you *are*.

Other login-type programs should also export SHELL, including sshd and
the various Display Managers.

If you want to know which shell you're currently in, the best command
I've found so far is:

ps -p $$

Works in Bourne family shells, csh family shells, SysV family ps, and
BSD family ps.  Of course, it's only as accurate as the output of ps,
which a clever user can spoof by overriding argv[0], or by creating
a symlink.

wooledg:~$ (exec -a tentaclesh bash)
wooledg:~$ ps -fp $$
UIDPID  PPID  C STIME TTY  TIME CMD
wooledg  19021  2244  0 07:47 pts/600:00:00 tentaclesh
wooledg:~$ ps -p $$
  PID TTY  TIME CMD
19021 pts/600:00:00 bash

wooledg:~$ ln -s /bin/bash tentaclesh
wooledg:~$ ./tentaclesh
wooledg:~$ ps -p $$
  PID TTY  TIME CMD
19029 pts/600:00:00 tentaclesh
wooledg:~$ ps -fp $$
UIDPID  PPID  C STIME TTY  TIME CMD
wooledg  19029  2244  0 07:51 pts/600:00:00 ./tentaclesh

ps's output is inherently unreliable, but "ps -p $$" with *NO* other
options gives you the best chance you will get.  Still, nothing is
perfect.

Re: Bash Question

[Rainer Dorsch]

Am Donnerstag, 6. Juli 2017, 11:50:44 CEST schrieb to...@tuxteam.de:
> On Thu, Jul 06, 2017 at 09:57:50AM +0100, Darac Marjal wrote:
> > On Thu, Jul 06, 2017 at 12:22:29AM +0200, Javier Barroso wrote:
> > >Hi,
> > >
> > >On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:
> > >>Hi,
> > >>
> > >>
> > >>
> > >>can anybody help to explain what is going on here ?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>rd@mohot:~$ echo $SHELL
> > >>/bin/bash
> > >>rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
> > >>bad
> > >>rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
> > >>good
> > >>rd@mohot:~$
> > >>
> > >>How can abc sort before and after dec at the same time?
> > >
> > >You need to scape "<" and ">":
> > >
> > >if [ "abc" \> "dec" ] ; then ... ;fi
> > >if [ "abc" '>' "dec" ]; then ... ; fi
> > >if [ "abc" ">" "dec" ]; then ... ; fi
> > >
> > >
> > >Delete "dec" file, ( ">" is redirection in bash, so you was creating that
> > >file> 
> > That's a very good point. ">" and "<" are NOT the greater-than/less-than
> > operators in bash.
> 
> They are (in bash: see below!) -- just check bash's manual page under
> "conditional expressions".
> 
> For strings, they list '==' and '=', '!=', '<' and '>'.
> 
> Now *if* you use '[' (single square bracket) as above, you are not using
> bash's built in [this is a little white lie[1], see below], but the external
> command 'test' or some cousin of that (just try "ls -l /usr/bin/[" to see
> what I mean. This one doesn't understand < and >.
> 
> If you want bash's builtin, use '[[' (double square bracket). It's faster
> (one less fork/exec), but also more convenient, because it "knows" that
> there's special syntax inside, so you don't need to escape < and > (as
> someone pointed out in this thread, see (again) below).
> 
> This works:
> 
>   if [[ "abc" < "bcd" ]] ; then  echo "yo" ; else echo "no" ; fi
> 
> Or this
> 
>   if [[ -n "abc" && ( "abc" < "bcd" ) ]] ; then  echo "yo" ; else echo "no"
> ; fi
> 
> (note I didn't have to escape the parens, which would wreak havoc
> elsewhere in the command line, because they have a special meaning
> for the shell, and the shell does expansion before calling commands.
> Only a builtin can achieve that).
> 
> Now try this:
> 
>   if [ "abc" < "bcd" ] ; then  echo "yo" ; else echo "no" ; fi
> 
> (note I chose '<' -- and hope there's no file 'bcd' lying around).
> Then I get:
> 
>   bash: bcd: No such file or directory
> 
> Now this all was a lie :-)
> 
> Or half. The '[' can be a builtin, after all (in bash). You can
> switch that on or off with the enable -- uh -- builtin.
> 
> Just type "help enable" at your favourite bash instance to learn
> about that.
> 
> But the '[' builtin has to behave as far as possible like the
> /usr/bin/[ of yore (aka POSIX 'test'). Including the way the
> shell "expands its innards" before handing things to the command.
> 
> That's why there is [[. Much easier to write and much easier on
> the eye.
> 
> BUT: this all won't work on dash (Debian's preferred non-interactive
> shell: much smaller and faster). There you have to spell things like
> so:
> 
>   if [ "abc" \< "bcd" ] ; then  echo "yo" ; else echo "no" ; fi
> 
> So dash's '[' is a builtin too (remember: /usr/bin/[ doesn't grok
> '<' at all). But dash hasn't the '[[' with its syntactic convenience.
> 
> Hope that helps, somewhat :-)
> 

Many thanks for all the answers (and scaring that kmail just omitted some 
stuff in the Text mail and just included it in the HTML part...this time w/o 
html). They helped a lot to solve my problem...

Thanks again
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Re: Bash Question

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, Jul 06, 2017 at 09:57:50AM +0100, Darac Marjal wrote:
> On Thu, Jul 06, 2017 at 12:22:29AM +0200, Javier Barroso wrote:
> >Hi,
> >
> >On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:
> >>Hi,
> >>
> >>
> >>
> >>can anybody help to explain what is going on here ?
> >>
> >>
> >>
> >>
> >>
> >>rd@mohot:~$ echo $SHELL
> >>/bin/bash
> >>rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
> >>bad
> >>rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
> >>good
> >>rd@mohot:~$
> >>
> >>How can abc sort before and after dec at the same time?
> >
> >You need to scape "<" and ">":
> >
> >if [ "abc" \> "dec" ] ; then ... ;fi
> >if [ "abc" '>' "dec" ]; then ... ; fi
> >if [ "abc" ">" "dec" ]; then ... ; fi
> >
> >
> >Delete "dec" file, ( ">" is redirection in bash, so you was creating that 
> >file
> 
> That's a very good point. ">" and "<" are NOT the greater-than/less-than
> operators in bash.

They are (in bash: see below!) -- just check bash's manual page under
"conditional expressions".

For strings, they list '==' and '=', '!=', '<' and '>'.

Now *if* you use '[' (single square bracket) as above, you are not using
bash's built in [this is a little white lie[1], see below], but the external
command 'test' or some cousin of that (just try "ls -l /usr/bin/[" to see
what I mean. This one doesn't understand < and >.

If you want bash's builtin, use '[[' (double square bracket). It's faster
(one less fork/exec), but also more convenient, because it "knows" that
there's special syntax inside, so you don't need to escape < and > (as
someone pointed out in this thread, see (again) below).

This works:

  if [[ "abc" < "bcd" ]] ; then  echo "yo" ; else echo "no" ; fi

Or this

  if [[ -n "abc" && ( "abc" < "bcd" ) ]] ; then  echo "yo" ; else echo "no" ; fi

(note I didn't have to escape the parens, which would wreak havoc
elsewhere in the command line, because they have a special meaning
for the shell, and the shell does expansion before calling commands.
Only a builtin can achieve that).

Now try this:

  if [ "abc" < "bcd" ] ; then  echo "yo" ; else echo "no" ; fi

(note I chose '<' -- and hope there's no file 'bcd' lying around).
Then I get:

  bash: bcd: No such file or directory

Now this all was a lie :-)

Or half. The '[' can be a builtin, after all (in bash). You can
switch that on or off with the enable -- uh -- builtin.

Just type "help enable" at your favourite bash instance to learn
about that.

But the '[' builtin has to behave as far as possible like the
/usr/bin/[ of yore (aka POSIX 'test'). Including the way the
shell "expands its innards" before handing things to the command.

That's why there is [[. Much easier to write and much easier on
the eye.

BUT: this all won't work on dash (Debian's preferred non-interactive
shell: much smaller and faster). There you have to spell things like
so:

  if [ "abc" \< "bcd" ] ; then  echo "yo" ; else echo "no" ; fi

So dash's '[' is a builtin too (remember: /usr/bin/[ doesn't grok
'<' at all). But dash hasn't the '[[' with its syntactic convenience.

Hope that helps, somewhat :-)

Cheers
[1] OK, OK. A dirty grey lie. Read on :-)

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlleB/QACgkQBcgs9XrR2kZQqgCfbCXMBkw2vwJd2xtfqNSc2/bI
NBkAn1MM8uGnehVTxNQWAP07ptBwJSI9
=r8rB
-END PGP SIGNATURE-

Re: Bash Question

[Darac Marjal]

On Thu, Jul 06, 2017 at 12:22:29AM +0200, Javier Barroso wrote:

Hi,

On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:

Hi,



can anybody help to explain what is going on here ?





rd@mohot:~$ echo $SHELL
/bin/bash
rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
bad
rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
good
rd@mohot:~$

How can abc sort before and after dec at the same time?


You need to scape "<" and ">":

if [ "abc" \> "dec" ] ; then ... ;fi
if [ "abc" '>' "dec" ]; then ... ; fi
if [ "abc" ">" "dec" ]; then ... ; fi


Delete "dec" file, ( ">" is redirection in bash, so you was creating that file


That's a very good point. ">" and "<" are NOT the greater-than/less-than
operators in bash. [ "abc" > "dec" ] tests whether the result of "abc"
can be written to the file "dec". Note, however, the subtle difference
between, say [ echo "abc" > "dec" ] where echo executes and copies its
arguments to stdout, which is then written to the file - the success of
this operation is tested; [ "abc" > "dec" ] will try to run "abc". It
looks like bash will interpret the string as a command, so this is
equivalent to [ abc > dec ], i.e. running the command "abc" and
redirecting its output to the file "dec".

The correct operators are actually "-lt" and "-gt". However, these
operators only work on INTEGERs. If you really need to test for "sorts
before", then you may need to resort to using sort itself. 



Regards



--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Bash Question

[David]

On 6 July 2017 at 07:53, der.hans  wrote:
>
> "$SHELL" is a builtin variable that tells you what shell you're currently
> running.

No, that's "not accurate", as indeed you wrote later.

Shells do not set this variable to identify themselves.

This can be easily tested by starting any shell interactively and inspecting
$SHELL.

For example, in a terminal start a 'dash' shell and then run 'echo $SHELL'
inside it.

For more enlightenment, start a 'dash' shell with 'SHELL=foo dash' and
run 'echo $SHELL' inside it.

Below I refer to man pages (on jessie). I have not read any relevant
source code, nor do I know if systemd does anything different, someone
else is welcome to comment on that.

On jessie, 'man 1 login', states that it sets SHELL. I understand this to
mean that 'login' exports SHELL as an environment variable to child
processes of 'login'.

I believe 'login' sets SHELL to the value of the user's login shell, as read
from /etc/passwd. Once. And after that it does not change.

And 'man bash' states that 'bash' sets SHELL only if it was previously not
set, and that in that situation it sets SHELL to the value of the user's login
shell.

And 'man dash' doesn't mention SHELL, so I presume it does not touch
it at all.

> When using subshells ( including a shell script ) I find it to
> not be accurate. Could well be that I just don't consistently quote it
> properly.

It is accurate, just not in the way you imagined. Quoting isn't the reason :)

It is simply that the "shell you're currently running" can easily be different
to the login shell, which is what $SHELL is expected to contain.

Re: Bash Question

[Jonathan Marquardt]

On Wed, Jul 05, 2017 at 10:31:02PM +, der.hans wrote:
> Am 06. Jul, 2017 schwätzte Jonathan Marquardt so:
> 
> > On Wed, Jul 05, 2017 at 09:53:15PM +, der.hans wrote:
> > > When running the command, your current shell evaluates the variable and
> > > replaces it with the variable's value before starting the echo command.
> > > When echo is run the command has already turned into "echo /bin/bash" or
> > > whatever your shell is, then echo produces "/bin/bash" as the output.
> > 
> > Yes, I thnk that OP's problem is that there is no output, probably because 
> > the
> > variable is not declared or empty.
> 
> Javier's response hints at the mystery.
> 
> The plain text version of the email stopped after the "echo $SHELL" line,
> but there are a couple if statements and a question in the html version.

Wow! Indeed, the plain text version is missig something. Another reason to
follow the netiquette and stop sending these stupid HTML mails...

Re: Bash Question

[Phil Wyett]

On Wed, 2017-07-05 at 23:12 +0200, Rainer Dorsch wrote:
> Hi,
>  
> can anybody help to explain what is going on here ?
>  
>  
> rd@mohot:~$ echo $SHELL 
> /bin/bash 
> rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi   
> bad 
> rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi 
> good 
> rd@mohot:~$ 
> 
> How can abc sort before and after dec at the same time?
>  
> Thanks
> Rainer
>  
>  
> -- 
> Rainer Dorsch
> http://bokomoko.de/


Hi,

Not sure what you are exactly trying to accomplish and you may need
to explain further.

If you want to basic string compare:

if [[ "abc" < "dec" ]]; then echo true; else echo false; fi

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Twitter: kathenasorg

Instagram: kathenasorg

signature.asc
Description: This is a digitally signed message part

Re: Bash Question

[der.hans]

Am 06. Jul, 2017 schwätzte Jonathan Marquardt so:


On Wed, Jul 05, 2017 at 09:53:15PM +, der.hans wrote:

When running the command, your current shell evaluates the variable and
replaces it with the variable's value before starting the echo command.
When echo is run the command has already turned into "echo /bin/bash" or
whatever your shell is, then echo produces "/bin/bash" as the output.


Yes, I thnk that OP's problem is that there is no output, probably because the
variable is not declared or empty.


Javier's response hints at the mystery.

The plain text version of the email stopped after the "echo $SHELL" line,
but there are a couple if statements and a question in the html version.

ciao,

der.hans
--
#  https://www.LuftHans.com/https://www.PhxLinux.org/
#  "So the environment is not a luxury ... It is an economically important
#  insurance policy whose wisdom we ignore at our peril."
#  -- Klaus Toepfer, U.N. environment agency Executive Director

Re: Bash Question

[Javier Barroso]

Hi,

On Wed, Jul 5, 2017 at 11:12 PM, Rainer Dorsch  wrote:
> Hi,
>
>
>
> can anybody help to explain what is going on here ?
>
>
>
>
>
> rd@mohot:~$ echo $SHELL
> /bin/bash
> rd@mohot:~$ if [ "abc" > "dec" ]; then echo bad; fi
> bad
> rd@mohot:~$ if [ "abc" < "dec" ]; then echo good; fi
> good
> rd@mohot:~$
>
> How can abc sort before and after dec at the same time?

You need to scape "<" and ">":

if [ "abc" \> "dec" ] ; then ... ;fi
if [ "abc" '>' "dec" ]; then ... ; fi
if [ "abc" ">" "dec" ]; then ... ; fi


Delete "dec" file, ( ">" is redirection in bash, so you was creating that file

Regards

Re: Bash Question

[Jonathan Marquardt]

On Wed, Jul 05, 2017 at 09:53:15PM +, der.hans wrote:
> When running the command, your current shell evaluates the variable and
> replaces it with the variable's value before starting the echo command.
> When echo is run the command has already turned into "echo /bin/bash" or
> whatever your shell is, then echo produces "/bin/bash" as the output.

Yes, I thnk that OP's problem is that there is no output, probably because the 
variable is not declared or empty.

Re: Bash Question

[der.hans]

Am 05. Jul, 2017 schwätzte Rainer Dorsch so:

moin moin Rainer,


can anybody help to explain what is going on here ?


rd@mohot:~$ echo $SHELL


Not sure what level you're asking about, so I will cover a couple levels
of information. Read the ones that are appropriate :).

echo is a a command that repeats back text.

"$SHELL" is a builtin variable that tells you what shell you're currently
running. When using subshells ( including a shell script ) I find it to
not be accurate. Could well be that I just don't consistently quote it
properly.

When running the command, your current shell evaluates the variable and
replaces it with the variable's value before starting the echo command.
When echo is run the command has already turned into "echo /bin/bash" or
whatever your shell is, then echo produces "/bin/bash" as the output.

ciao,

der.hans
--
#  https://www.LuftHans.com/https://www.PhxLinux.org/
#  "It is appallingly obvious that our technology exceeds our humanity."
#   -- Einstein

Re: Bash Question

[Sven Joachim]

On 2017-07-05 23:12 +0200, Rainer Dorsch wrote:

> Hi,
>
> can anybody help to explain what is going on here ?
>
>
> rd@mohot:~$ echo $SHELL 

Without any information how you started your shell, it's hard to tell.
For example, xterm version 321 had the bug that it would clear the SHELL
variable from the environment, but that was quickly detected and
corrected[1].

Cheers,
   Sven


1. https://bugs.debian.org/809646

Bash Question

[Rainer Dorsch]

Hi,

can anybody help to explain what is going on here ?


rd@mohot:~$ echo $SHELL 


Thanks
Rainer


-- 
Rainer Dorsch
http://bokomoko.de/

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 13:53:14 Thomas Schmitt wrote:

> Hi,
>
> > ++ /usr/bin/inotifywait -q -e close --format %f /var/spool/mail/
>
> From the man page i learn that you let it watch the whole directory.
> This way you get notifications about any file in there.
>
> The empty variable content possibly stems from this feature:
>   "-format 
>...
>%f
>When an event occurs within a directory, this will be replaced with
>the name of the File which caused the event to occur. Otherwise,
>this will be replaced with an empty string."
> But i have difficulties to imagine which "close" event could happen
> outside the directory and would still be noticed.
>
> It looks like you can avoid this condition by formatter %w and by
> watching only those mailbox files which you are interested in.
> I'd try this
>
>   /usr/bin/inotifywait -q -e close --format %w \
>/var/spool/mail/gene \
>/var/spool/mail/gene-from_linda \
>/var/spool/mail/amanda
>
> If InMail then contains full paths, like
>
>   /var/spool/mail/amanda
>
> i'd process them by command "basename":
>
>   InMail=$(basename "$InMail")
>
>
> But it seems you have blind time periods in your loop, during which
> inotifywait is not on guard and thus would not catch events.
> Not very reliable.
>
> Maybe you should additionally check the mtime stamps of the mailbox
> files and record them in little data files:
>
>   stamp=$(stat --format=%Y /var/spool/mail/gene)
>   if test "$stamp" -gt "$(cat "$HOME"/timestamp_gene)"
>   then
>  ... something changed in /var/spool/mail/gene ...
>   fi
>
> I have no proposal yet how to avoid processing the mailbox files
> while the fetcher programs are still operating on them.
> (This race condition arises already with your reaction on a reply
>  from inotifywait.)
>
inotifywait does that, only returning with the name when the file has 
been closed.

Now, I've been doing a little cleanup, so here is the current version
to pick apart. It IS working with no errors.
=
#!/bin/bash
# set -x
# this was a test, was /bin/sh above, but /bin/sh is a softlink to /bin/dash
# REQUIRES your distros inotify-tools package, assume kde/kmail in use
# but might be adaptable to other agents too
# requires a ~/log directory, so mkdir it before running it
# you will also need to either do the housekeeping of this file, or
# figure out how to make logrotate do it for you.

WatchDir=/var/spool/mail/

# Setup temporary log
Log=mail.log
Mlog=~/log
# in case it doesn't exist, make it
touch ${Mlog}/${Log}
# the command to send over dbus/dcop to make kmail pull the mailfile
#in /var/spool/mail

# First set method
Method=dcop
if [[ ${Method} = 'dbus' ]]
then
Cmd="/usr/bin/qdbus org.kde.kmail /KMail org.kde.kmail.kmail.checkMail"
fi
if [[ ${Method} = 'dcop' ]]
then
#or for dcop, use:
Cmd="/opt/trinity/bin/dcop kmail KMailIface checkMail"
fi

#  Now, do forever
while :
do
sleep 2
if [ $(pidof -s kmail) ]
then
echo -n "Kmail is running " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
sleep 1 # delay to give kmail a chance to settle in
# only start fetchmail once!
if [ $(pidof -s fetchmail) ]
then
sleep 1
echo "fetchmail already running " >>${Mlog}/${Log}
else
echo -n "starting fetchmail at " >>${Mlog}/${Log}
fetchmail -d 180 -t 60 --fetchmailrc 
/home/gene/.fetchmailrc >>${Mlog}/${Log} &
date -R >>${Mlog}/${Log}
fi
sleep 1 # delay to give kmail a chance to get its dcop/dbus 
sockets setup?
$cmd
while [ $(pidof -s kmail) ]
do
# I've found that stderr needs dumped to /dev/null, so
InMail=`/usr/bin/inotifywait -q -e close_write --format 
%f ${WatchDir}` # 2>&1 >/dev/null   
# and here it sits until inotifywait exits because of 
an incoming mail
# and time later it will exit, setting $InMail to 
something, so
# recheck to make sure kmail is still about before 
sending the signal
# as dbus/dcop seems to get a tummy ache if there is no 
receiver

if test "${InMail}" = "gene"
then
$Cmd
sleep 2
# log it
echo -n ${InMail} >>${Mlog}/${Log}
echo -n " @ " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
elif test "${InMail}" = "gene-from_linda"
then
 

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 10:08:33 David Wright wrote:

> On Mon 13 Jun 2016 at 10:19:46 (+0200), Thomas Schmitt wrote:
> > Gene Heskett wrote:
> > > if test ${InMail} = "gene"
> > > bin/mailwatcher: line 66: test: =: unary operator expected
> >
> > The syntax problem is most probably about missing "-quotes around
> > the variable ecaluation ${InMail} which would have to be empty to
> > cause the message:
> >
> >   $ test $notdefined = "hello world"
> >   -bash: test: =: unary operator expected
> >   $ test "$notdefined" = "hello world"
> >
> >   $ defined=x
> >   $ test $defined = "hello world"
> >   $
> >
> > Another negative syntax effect would happen if ${InMail} did consist
> > of more than one word:
> >
> >   $ multiword="x y"
> >   $ test $multiword = "hello world"
> >   -bash: test: too many arguments
> >
> > (On the other hand, "gene" does not need its quotes because the
> >  text is a single constant word. "hello world" needs them, because
> >  of the blank on the middel.)
> >
> > ---
> >
> > Is ${InMail} supposed to be empty ?
> > If not, then the script has another problem about properly setting
> > the variable.
> >
> >
> > Have a nice day :)
>
> Thomas, your patience appears unbounded. We have been to this place
> before:
>
> https://lists.debian.org/debian-user/2016/04/msg00652.html
>
Yes, I believe we have, but this time I understood the replies better, 
well enough to fix my warnings to the point that it is no longer needing 
to have its shell output sent to >/dev/null 2>&1 &.  That means I can 
fine tune it and adjust it with no more effort than a ctl+c and a rerun 
to check my changes.  That is a huge improvement right there, which is 
why I tendered thank you's to all who participated, and still do.

For the nonce, I believe this thread is cooked to perfection (until 
someone moves perfection, and I believe I've seen a Murphy's Law 
corollary on that subject, someplace in the last 75 years), so thanks 
again everybody, including you David. 

> Cheers,
> David.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 08:50:58 Jörg-Volker Peetz wrote:

> watch -d -n 1.5  ls -la /var/spool/mail/

Interesting tool, thank you.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: nother bash question

[Thomas Schmitt]

Hi,

> ++ /usr/bin/inotifywait -q -e close --format %f /var/spool/mail/

>From the man page i learn that you let it watch the whole directory.
This way you get notifications about any file in there.

The empty variable content possibly stems from this feature:
  "-format 
   ...
   %f
   When an event occurs within a directory, this will be replaced with
   the name of the File which caused the event to occur. Otherwise,
   this will be replaced with an empty string."
But i have difficulties to imagine which "close" event could happen
outside the directory and would still be noticed.

It looks like you can avoid this condition by formatter %w and by
watching only those mailbox files which you are interested in.
I'd try this

  /usr/bin/inotifywait -q -e close --format %w \
   /var/spool/mail/gene \
   /var/spool/mail/gene-from_linda \
   /var/spool/mail/amanda

If InMail then contains full paths, like

  /var/spool/mail/amanda

i'd process them by command "basename":

  InMail=$(basename "$InMail")


But it seems you have blind time periods in your loop, during which
inotifywait is not on guard and thus would not catch events.
Not very reliable.

Maybe you should additionally check the mtime stamps of the mailbox
files and record them in little data files:

  stamp=$(stat --format=%Y /var/spool/mail/gene)
  if test "$stamp" -gt "$(cat "$HOME"/timestamp_gene)"
  then
 ... something changed in /var/spool/mail/gene ...
  fi

I have no proposal yet how to avoid processing the mailbox files
while the fetcher programs are still operating on them.
(This race condition arises already with your reaction on a reply
 from inotifywait.)


In a newer mail from Gene:
> fetchmail fires off a session of mailfilter, which can nuke undesirables
> on the server so fetchmail never sees them, then fetchmail does the 
> pulling, hands it off to procmail for some deaths and diversions, and 
> puts what survives into one of 4 named files in /var/spool/mail/

And you cannot talk any of the participants into performing the
actions of $Cmd when it knows that the data are ready and no other
participant is manipulating them ?



Some shell nitpicking:

> # I've found that stderr needs dumped to /dev/null, so
> InMail=`/usr/bin/inotifywait -q -e close_write --format %f ${WatchDir}` 2>&1 
> >/dev/null

This line consumes stdout of inotifywait, redirects stderr of the empty
command after the variable assignment to stdout, and redirects original
stdout to /dev/null. (So if there was stderr output outside the ``-quotes
it would be shown on stdout.)
stderr of inotifywait is not redirected by this line.
See this example which puts "a" on stdout and "b" on stderr:

  $ x=`echo a ; echo b >&2` 2>&1 >/dev/null
  b
  $ echo "$x"
  a

Your comment suggests you want something like

  InMail=`/usr/bin/inotifywait -q -e close_write --format %f ${WatchDir} 
2>/dev/null`

which redirects stderr of inotifywait to /dev/null.
Since there is no command after the variable assignment, there is no
need to redirect its output.



Have a nice day :)

Thomas

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 06:34:00 Gene Heskett wrote:

> On Monday 13 June 2016 05:21:23 to...@tuxteam.de wrote:
> > On Mon, Jun 13, 2016 at 10:19:46AM +0200, Thomas Schmitt wrote:
> > > Hi,
> > >
> > > Gene Heskett wrote:
> > > > if test ${InMail} = "gene"
> > > > bin/mailwatcher: line 66: test: =: unary operator expected
> > >
> > > The syntax problem is most probably about missing "-quotes around
> > > the variable ecaluation ${InMail} which would have to be empty to
> > > cause the message:
> >
> > Agreed.
> >
> > If I may add something -- one of the most difficult things for shell
> > novices to wrap their head around is the interaction of command line
> > expansion and the commands themselves. This is one of the things
> > which make the shell very powerful [1], but you gotta get used to
> > it.
> >
> > Let's walk through your problem case (note that I'm restating
> > what Thomas said. It's just I know it's difficult and bears some
> > repeating :)
> >
> > You wrote:
> >
> >   test ${InMail} = "gene"
> >
> > Now the shell gets a first chance at it. Suppose ${InMail} is empty.
> > After variable expansion, you got:
> >
> >   test = "gene"
> >
> > (${InMail} was empty, so it gets replaced by nothing). Now that's
> > what the "if" gets fed with. It responds with "Eek! You told me
> > to compare *two* things and there's just one!
> >
> > One could argue "unary operator expected" is a strange way to
> > restate this. I didn't check, but I guess we're seeing too
> > deep into the bowels of if's parser.
> >
> > The solution is, as Thomas said, to put ${InMail} in double quotes.
> > It almost always is. The better solution is, of course: always
> > try to mentally follow what happens: first, expansion; then command.
> >
> > regards
> >
> > [1] "expressive" might be the more correct term.
> >
> > -- tomás
>
> In any event a pair of "" around the left argument silenced the
> warning, and it still works. However it may be that inotifywait is
> premature, as I see that InMail occasionall contains a hash name of
> the order of: + test _KQG,TdoXXB.coyote = gene
> + test _KQG,TdoXXB.coyote = gene-from_linda
> + test _KQG,TdoXXB.coyote = amanda
>
> which of course fails all 3 tests, and if I look a couple seconds
> later, there is no such file in that directory.  So I'm assuming the
> mailfile is being appended under a hashed up name & the real named
> file is nuked, and the merged result is then renamed to its correct
> name.  But thats just a swag, and we all know what a swag is. ;-)
>
> In any event, an incoming may be undetected until the magic of time
> actually returns the correct name, perhaps on the next message.  It
> seems to be, as I observe it, a pattern of every 3rd access to that
> directory.  There is of course no such pattern in the incoming mail.
>
> Perhaps this needs a more exacting look. But with what tool?
>
> Cheers, Gene Heskett

The script I just posted now has its trace thru one incoming email that 
looks like this
===
++ /usr/bin/inotifywait -q -e close_write --format %f /var/spool/mail/
+ InMail=gene
+ test gene = gene
+ /opt/trinity/bin/dcop kmail KMailIface checkMail
+ sleep 2
+ date -R
+ echo gene
++ pidof -s kmail
+ '[' 5179 ']'
++ /usr/bin/inotifywait -q -e close_write --format %f /var/spool/mail/
==

Which is just what I was trying to write. ;-) 
I believe I can nuke the set -x in line 2 now.

Many Thanks to all who replied.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 06:30:39 Thomas Schmitt wrote:

> Hi,
>
> i wrote:
> > > Is ${InMail} supposed to be empty ?
It is not supposed to be.  Empty only if I kill it with  a killall in practice.
>
> Gene Heskett wrote:
> > That is set by inotifywait's return of the name of the file that
> > procmail just closed.
>
> Hmm. I don't have inotifywait installed.
> According to http://linux.die.net/man/1/inotifywait it should put out
> lines like
>   CLOSE_WRITE:CLOSE goodfile

No, if the argument is set correctly, and the %f in the arguments at 
launch time are set, it returns only the name of the file that was 
closed, or it can be set to watch only the closing of files written to
as in this case.

In case someone wants to try it out, here is the script as it exists 
at this instant but it makes assumptions that you are on a first name
basis with both fetchmail and procmail too.  This completely offloads
the mail fetching by your email agent, in this case kmail, so  its
getmail functions are automatic, on demand and fractional seconds to do,
paced by the -d time argument in your ~/.fetchmailrc:
=
#!/bin/bash
set -x
# this was a test, was /bin/sh above, but /bin/sh is a softlink 
# to /bin/dash, which failed my testing
# REQUIRES your distros inotify-tools package, assumes kde/kmail in use
# but might be adaptable to other agents too
# requires a ~/log directory, so mkdir it before running this
# you will also need to either do the housekeeping of this file, or
# figure out how to make logrotate do it for you.
# when launching this, all output MUST be redirected >/dev/null 2>1 &
# like "/path/to/mailwatcher >/dev/null 2>&1 &"
# As inotifywait is not silent on launch even with the -q option
WatchDir=/var/spool/mail/
# Setup temporary log
Log=mail.log
Mlog=~/log
# in case it doesn't exist, make it
touch ${Mlog}/${Log}
# the command to send over dbus/dcop to make kmail pull the mailfile in 
/var/spool/mail

# First set method
Method=dcop
if [[ ${Method} = 'dbus' ]]
then
Cmd="/usr/bin/qdbus org.kde.kmail /KMail org.kde.kmail.kmail.checkMail"
fi
if [[ ${Method} = 'dcop' ]]
then
# or for dcop, use:
Cmd="/opt/trinity/bin/dcop kmail KMailIface checkMail"
fi

#  Now, do forever
while :
do
sleep 2
if [ $(pidof -s kmail) ]
then
echo -n "Kmail is running " >>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
sleep 1 # delay to give kmail a chance to settle in
# only start fetchmail once!
if [ $(pidof -s fetchmail) ]
then
sleep 1
else
echo -n "starting fetchmail at " >>${Mlog}/${Log}
fetchmail -d 180 -t 60 --fetchmailrc 
/home/gene/.fetchmailrc >>${Mlog}/${Log} &
date -R >>${Mlog}/${Log}
fi
sleep 1 # delay to give kmail a chance to get its dcop/dbus 
sockets setup?
$cmd #probably superfolous
while [ $(pidof -s kmail) ]
do
# I've found that stderr needs dumped to /dev/null, so
InMail=`/usr/bin/inotifywait -q -e close_write --format 
%f ${WatchDir}` 2>&1 >/dev/null 
# and here it sits until inotifywait exits because of 
an incoming mail
# and sometime later it will exit, setting $InMail to 
something.

if test "${InMail}" = "gene"
then
$Cmd
sleep 2
# log it
date -R >>${Mlog}/${Log}
echo ${InMail} >>${Mlog}/${Log}
elif test "${InMail}" = "gene-from_linda"
then
$Cmd
sleep 2
# log it
date -R >>${Mlog}/${Log}
echo ${InMail} >>${Mlog}/${Log}
elif test "${InMail}" = "amanda"
then
$Cmd
sleep 2
# log it
date -R >>${Mlog}/${Log}
echo ${InMail} >>${Mlog}/${Log}
fi

done
# we don't have a pidof kmail, log that its gone
echo -n "Kmails pid is missing - it has stopped 
">>${Mlog}/${Log}
date -R >>${Mlog}/${Log}
# Now, kill fetchmail too, and this is ok to do
killall fetchmail
# get rid of a waiting inotifywait, but this is not inotifywait 
instance
# sensitive and may kill the one for cocoprint.
killall 

Re: nother bash question

[Thomas Schmitt]

Hi,

David Wright wrote:
> Thomas, your patience appears unbounded.

That's a character strength which a programmer must have
at least in part.


> https://lists.debian.org/debian-user/2016/04/msg00652.html

Yeah. I advised Gene to put "-quotes around variable evaluations.
Now we have the educational example why this is best practice.

Currently i expect the next insight to arise when Gene describes
his shell code which derives the variable content from the output
of inotifywait(1).
(Describing the own software to others is often a good way to find
 the wrong assumptions and mental short circuits which cause the
 software to behave in an undesired way. Even if the others just
 sit there and say "ahum".)


Have a nice day :)

Thomas

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 05:21:23 to...@tuxteam.de wrote:

> On Mon, Jun 13, 2016 at 10:19:46AM +0200, Thomas Schmitt wrote:
> > Hi,
> >
> > Gene Heskett wrote:
> > > if test ${InMail} = "gene"
> > > bin/mailwatcher: line 66: test: =: unary operator expected
> >
> > The syntax problem is most probably about missing "-quotes around
> > the variable ecaluation ${InMail} which would have to be empty to
> > cause the message:
>
> Agreed.
>
> If I may add something -- one of the most difficult things for shell
> novices to wrap their head around is the interaction of command line
> expansion and the commands themselves. This is one of the things
> which make the shell very powerful [1], but you gotta get used to it.
>
> Let's walk through your problem case (note that I'm restating
> what Thomas said. It's just I know it's difficult and bears some
> repeating :)
>
> You wrote:
>
>   test ${InMail} = "gene"
>
> Now the shell gets a first chance at it. Suppose ${InMail} is empty.
> After variable expansion, you got:
>
>   test = "gene"
>
> (${InMail} was empty, so it gets replaced by nothing). Now that's
> what the "if" gets fed with. It responds with "Eek! You told me
> to compare *two* things and there's just one!
>
> One could argue "unary operator expected" is a strange way to
> restate this. I didn't check, but I guess we're seeing too
> deep into the bowels of if's parser.
>
> The solution is, as Thomas said, to put ${InMail} in double quotes.
> It almost always is. The better solution is, of course: always
> try to mentally follow what happens: first, expansion; then command.

Well, while the double quotes fixed it, the original actually worked.  
The target action of sending kmail a getmail command was carried out,

Another time killer was doing a pidof -s kmail 3x in the main loop, that 
is handled by the while, do, done around it all.  So I just took that 
out.

And I'm still puzzled.  This is a single incoming mail:

+ InMail=_OLB,AltXXB.coyote
+ test _OLB,AltXXB.coyote = gene
+ test _OLB,AltXXB.coyote = gene-from_linda
+ test _OLB,AltXXB.coyote = amanda

all test failed so back at the while pidof -s kmail

++ pidof -s kmail
+ '[' 5179 ']'

kmail is there, launch the inotifywait session.

++ /usr/bin/inotifywait -q -e close --format %f /var/spool/mail/
+ InMail=gene
+ test gene = gene
+ /opt/trinity/bin/dcop kmail KMailIface checkMail
+ date -R
+ echo gene

back at the top of the while

++ pidof -s kmail
+ '[' 5179 ']'
++ /usr/bin/inotifywait -q -e close --format %f /var/spool/mail/

So here inotifywait is seeing kmail's close as it read the file and 
zeroed it

+ InMail=gene
+ test gene = gene
+ /opt/trinity/bin/dcop kmail KMailIface checkMail
+ date -R
+ echo gene
++ pidof -s kmail
+ '[' 5179 ']'
++ /usr/bin/inotifywait -q -e close --format %f /var/spool/mail/

So its getting 2 checkmails because it is seeing its own activities. Put 
in a sleep 1 after send the getmail to kmail to see if thats enough time 
killer to miss that.  Wasn't enough trying sleep 2 before relaunching 
inotifywait now.  And watching paint dry, only denied spam or nothing so 
far.

Send this, so I'll get the echo as a test msg. :)

> regards
>
> [1] "expressive" might be the more correct term.
>
> -- tomás


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: nother bash question

[David Wright]

On Mon 13 Jun 2016 at 05:17:42 (-0400), Gene Heskett wrote:
> On Monday 13 June 2016 04:19:46 Thomas Schmitt wrote:
> 
> > Hi,
> >
> > Gene Heskett wrote:
> > > if test ${InMail} = "gene"
> > > bin/mailwatcher: line 66: test: =: unary operator expected
> >
> > The syntax problem is most probably about missing "-quotes around
> > the variable ecaluation ${InMail} which would have to be empty to
> > cause the message:
> >
> >   $ test $notdefined = "hello world"
> >   -bash: test: =: unary operator expected
> >   $ test "$notdefined" = "hello world"
> >
> >   $ defined=x
> >   $ test $defined = "hello world"
> >   $
> >
> > Another negative syntax effect would happen if ${InMail} did consist
> > of more than one word:
> 
> The likelyhood of that is .000slim to none, my procmail would have to 
> have developed a tummy ache, and I'd have lots bigger problems.

We have been here before, too.

https://lists.debian.org/debian-user/2016/04/msg00675.html

So why do you want to discover some future problem in procmail by
having this script blow up?

> >   $ multiword="x y"
> >   $ test $multiword = "hello world"
> >   -bash: test: too many arguments
> >
> > (On the other hand, "gene" does not need its quotes because the
> >  text is a single constant word. "hello world" needs them, because
> >  of the blank on the middel.)
> Ahh, I see.
> > ---
> >
> > Is ${InMail} supposed to be empty ?
> > If not, then the script has another problem about properly setting
> > the variable.
> >
> That is set by inotifywait's return of the name of the file that procmail 
> just closed.  It may not be a match with my tests as there a virii file 
> there too.  But clamd isn't catching but maybe 10% of that.
> 
> I should probably clear InName to "", but inotifywait has been coping 
> with that for about a decade :)

Hence the reference to "when it *is* empty, it'll be in five years time".

I can't understand why you prefer to have to check a load of logic
(which you outlined in more detail in
https://lists.debian.org/debian-user/2016/04/msg00676.html
) rather than write a few defensively-written tests.

Cheers,
David.

Re: nother bash question

[David Wright]

On Mon 13 Jun 2016 at 10:19:46 (+0200), Thomas Schmitt wrote:
> Gene Heskett wrote:
> > if test ${InMail} = "gene"
> > bin/mailwatcher: line 66: test: =: unary operator expected
> 
> The syntax problem is most probably about missing "-quotes around
> the variable ecaluation ${InMail} which would have to be empty to
> cause the message:
> 
>   $ test $notdefined = "hello world"
>   -bash: test: =: unary operator expected
>   $ test "$notdefined" = "hello world"
> 
>   $ defined=x
>   $ test $defined = "hello world"
>   $
> 
> Another negative syntax effect would happen if ${InMail} did consist
> of more than one word:
> 
>   $ multiword="x y"
>   $ test $multiword = "hello world"
>   -bash: test: too many arguments
> 
> (On the other hand, "gene" does not need its quotes because the
>  text is a single constant word. "hello world" needs them, because
>  of the blank on the middel.)
> 
> ---
> 
> Is ${InMail} supposed to be empty ?
> If not, then the script has another problem about properly setting
> the variable.
> 
> 
> Have a nice day :)

Thomas, your patience appears unbounded. We have been to this place before:

https://lists.debian.org/debian-user/2016/04/msg00652.html

Cheers,
David.

Re: nother bash question

[Jörg-Volker Peetz]

Gene Heskett wrote on 06/13/16 12:34:

> In any event a pair of "" around the left argument silenced the warning, 
> and it still works. However it may be that inotifywait is premature, as 
> I see that InMail occasionall contains a hash name of the order of:
> + test _KQG,TdoXXB.coyote = gene
> + test _KQG,TdoXXB.coyote = gene-from_linda
> + test _KQG,TdoXXB.coyote = amanda
> 
> which of course fails all 3 tests, and if I look a couple seconds later, 
> there is no such file in that directory.  So I'm assuming the mailfile 
> is being appended under a hashed up name & the real named file is nuked, 
> and the merged result is then renamed to its correct name.  But thats 
> just a swag, and we all know what a swag is. ;-)
> 
> In any event, an incoming may be undetected until the magic of time 
> actually returns the correct name, perhaps on the next message.  It 
> seems to be, as I observe it, a pattern of every 3rd access to that 
> directory.  There is of course no such pattern in the incoming mail.
> 
> Perhaps this needs a more exacting look. But with what tool?
> 
> Cheers, Gene Heskett

To do it at least interactively, there is the nice tool "watch" from the package
"procps":
To see what's going on in directory /path/to/xxx, command something like

  watch -d -n 1.5  ls -la /path/to/xxx

from a terminal big enough to show all files without scrolling.
The switch "-n 1.5" specifies the update interval in seconds.
If you only want to watch the 20 newest files, command

  watch -d -n 1.5  'ls -latr /path/to/xxx | tail -20'

To stop watching, press Ctrl-C.

Regards,
jvp.

Re: nother bash question

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 13, 2016 at 12:30:39PM +0200, Thomas Schmitt wrote:
> Hi,

[...]

> to...@tuxteam.de wrote:
> > One could argue "unary operator expected" is a strange way to
> > restate this.
> 
> It's the way how the gild of land surveyors and bean counters expresses
> itself:

Thomas, you always let some sun into the most sordid affairs :-)

(thanks for the good explanation)

regards
- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldej6cACgkQBcgs9XrR2kbqFwCfT85CbUitT5ApHcJqyfIuYmhp
rqsAn1SYa3HDvQHwmwcPlp2mzCvYhLy7
=ce+n
-END PGP SIGNATURE-

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 05:21:23 to...@tuxteam.de wrote:

> On Mon, Jun 13, 2016 at 10:19:46AM +0200, Thomas Schmitt wrote:
> > Hi,
> >
> > Gene Heskett wrote:
> > > if test ${InMail} = "gene"
> > > bin/mailwatcher: line 66: test: =: unary operator expected
> >
> > The syntax problem is most probably about missing "-quotes around
> > the variable ecaluation ${InMail} which would have to be empty to
> > cause the message:
>
> Agreed.
>
> If I may add something -- one of the most difficult things for shell
> novices to wrap their head around is the interaction of command line
> expansion and the commands themselves. This is one of the things
> which make the shell very powerful [1], but you gotta get used to it.
>
> Let's walk through your problem case (note that I'm restating
> what Thomas said. It's just I know it's difficult and bears some
> repeating :)
>
> You wrote:
>
>   test ${InMail} = "gene"
>
> Now the shell gets a first chance at it. Suppose ${InMail} is empty.
> After variable expansion, you got:
>
>   test = "gene"
>
> (${InMail} was empty, so it gets replaced by nothing). Now that's
> what the "if" gets fed with. It responds with "Eek! You told me
> to compare *two* things and there's just one!
>
> One could argue "unary operator expected" is a strange way to
> restate this. I didn't check, but I guess we're seeing too
> deep into the bowels of if's parser.
>
> The solution is, as Thomas said, to put ${InMail} in double quotes.
> It almost always is. The better solution is, of course: always
> try to mentally follow what happens: first, expansion; then command.
>
> regards
>
> [1] "expressive" might be the more correct term.
>
> -- tomás

In any event a pair of "" around the left argument silenced the warning, 
and it still works. However it may be that inotifywait is premature, as 
I see that InMail occasionall contains a hash name of the order of:
+ test _KQG,TdoXXB.coyote = gene
+ test _KQG,TdoXXB.coyote = gene-from_linda
+ test _KQG,TdoXXB.coyote = amanda

which of course fails all 3 tests, and if I look a couple seconds later, 
there is no such file in that directory.  So I'm assuming the mailfile 
is being appended under a hashed up name & the real named file is nuked, 
and the merged result is then renamed to its correct name.  But thats 
just a swag, and we all know what a swag is. ;-)

In any event, an incoming may be undetected until the magic of time 
actually returns the correct name, perhaps on the next message.  It 
seems to be, as I observe it, a pattern of every 3rd access to that 
directory.  There is of course no such pattern in the incoming mail.

Perhaps this needs a more exacting look. But with what tool?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: nother bash question

[Thomas Schmitt]

Hi,

i wrote:
> > Is ${InMail} supposed to be empty ?

Gene Heskett wrote:
> That is set by inotifywait's return of the name of the file that procmail 
> just closed. 

Hmm. I don't have inotifywait installed.
According to http://linux.die.net/man/1/inotifywait it should put out
lines like
  CLOSE_WRITE:CLOSE goodfile

I guess you pick the second word or the line end of such a line.
It would be interesting to see how you do this.


> I should probably clear InName to "", but inotifywait has been coping 
> with that for about a decade :)

All is well as long as ${InMail} is perceived by the shell parser as
a single shell word. (I.e. a text snippet which the shell parser recognizes
as a unit.)

So i assume that the problem is in the text which your script picks from
the inotifywait reply.
Add to the script some commands which print the line and the text it
picks. Then you get hints what might go wrong and some an to play with
in the shell dialog line.

-
Detour into theory:

> > > bin/mailwatcher: line 66: test: =: unary operator expected
to...@tuxteam.de wrote:
> One could argue "unary operator expected" is a strange way to
> restate this.

It's the way how the gild of land surveyors and bean counters expresses
itself:
Unary operators are for example the logical negation ("not") or the
arithmetic sign ("-").
Binary operators are logical conjunction ("and") or arithmetic
subtraction ("-" again (nobody promised math to be straightforward)).

Since there is only one non-operator given ("gene"), the parser is
unwilling to accept any binary operator. The message is then just an
indication that the programmer was either to concentrated on the
job or that the parser of test does not know enough about its boss
program.
A user-aware programmer of a boss-program-aware parser could well
report: "Operator '=' expects two operands. Only one is given."

Beware: '=' without any operand is considered to be syntactically
correct and evaluates as "true":

  $ test =
  $ echo $?
  0

because of:
  
https://www.gnu.org/software/coreutils/manual/html_node/test-invocation.html#test-invocation
  "If expression is omitted, test returns false. If expression is a single
   argument, test returns false if the argument is null and true otherwise."

I guess the founders of Unix introduced this rule when a byte of storage
was worth more than a dollar.


Have a nice day :)

Thomas

Re: nother bash question

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Jun 13, 2016 at 10:19:46AM +0200, Thomas Schmitt wrote:
> Hi,
> 
> Gene Heskett wrote:
> > if test ${InMail} = "gene"
> > bin/mailwatcher: line 66: test: =: unary operator expected
> 
> The syntax problem is most probably about missing "-quotes around
> the variable ecaluation ${InMail} which would have to be empty to
> cause the message:

Agreed.

If I may add something -- one of the most difficult things for shell
novices to wrap their head around is the interaction of command line
expansion and the commands themselves. This is one of the things
which make the shell very powerful [1], but you gotta get used to it.

Let's walk through your problem case (note that I'm restating
what Thomas said. It's just I know it's difficult and bears some
repeating :)

You wrote:

  test ${InMail} = "gene"

Now the shell gets a first chance at it. Suppose ${InMail} is empty.
After variable expansion, you got:

  test = "gene"

(${InMail} was empty, so it gets replaced by nothing). Now that's
what the "if" gets fed with. It responds with "Eek! You told me
to compare *two* things and there's just one!

One could argue "unary operator expected" is a strange way to
restate this. I didn't check, but I guess we're seeing too
deep into the bowels of if's parser.

The solution is, as Thomas said, to put ${InMail} in double quotes.
It almost always is. The better solution is, of course: always
try to mentally follow what happens: first, expansion; then command.

regards

[1] "expressive" might be the more correct term.

- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAldeexMACgkQBcgs9XrR2kZavQCdFzPmHOqAeLeBRDiEQvkRN0i/
2ksAoIEiv3jza1zaUih7nHxomteT0hHr
=+rsl
-END PGP SIGNATURE-

Re: nother bash question

[Gene Heskett]

On Monday 13 June 2016 04:19:46 Thomas Schmitt wrote:

> Hi,
>
> Gene Heskett wrote:
> > if test ${InMail} = "gene"
> > bin/mailwatcher: line 66: test: =: unary operator expected
>
> The syntax problem is most probably about missing "-quotes around
> the variable ecaluation ${InMail} which would have to be empty to
> cause the message:
>
>   $ test $notdefined = "hello world"
>   -bash: test: =: unary operator expected
>   $ test "$notdefined" = "hello world"
>
>   $ defined=x
>   $ test $defined = "hello world"
>   $
>
> Another negative syntax effect would happen if ${InMail} did consist
> of more than one word:

The likelyhood of that is .000slim to none, my procmail would have to 
have developed a tummy ache, and I'd have lots bigger problems.
>
>   $ multiword="x y"
>   $ test $multiword = "hello world"
>   -bash: test: too many arguments
>
> (On the other hand, "gene" does not need its quotes because the
>  text is a single constant word. "hello world" needs them, because
>  of the blank on the middel.)
Ahh, I see.
> ---
>
> Is ${InMail} supposed to be empty ?
> If not, then the script has another problem about properly setting
> the variable.
>
That is set by inotifywait's return of the name of the file that procmail 
just closed.  It may not be a match with my tests as there a virii file 
there too.  But clamd isn't catching but maybe 10% of that.

I should probably clear InName to "", but inotifywait has been coping 
with that for about a decade :)
> Have a nice day :)

It's better so far, but its also way to early, so back for some more 
zz's.  Thank you.
>
> Thomas


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: nother bash question

[Thomas Schmitt]

Hi,

Gene Heskett wrote:
> if test ${InMail} = "gene"
> bin/mailwatcher: line 66: test: =: unary operator expected

The syntax problem is most probably about missing "-quotes around
the variable ecaluation ${InMail} which would have to be empty to
cause the message:

  $ test $notdefined = "hello world"
  -bash: test: =: unary operator expected
  $ test "$notdefined" = "hello world"

  $ defined=x
  $ test $defined = "hello world"
  $

Another negative syntax effect would happen if ${InMail} did consist
of more than one word:

  $ multiword="x y"
  $ test $multiword = "hello world"
  -bash: test: too many arguments

(On the other hand, "gene" does not need its quotes because the
 text is a single constant word. "hello world" needs them, because
 of the blank on the middel.)

---

Is ${InMail} supposed to be empty ?
If not, then the script has another problem about properly setting
the variable.


Have a nice day :)

Thomas

nother bash question

[Gene Heskett]

Greetings bashers;
I have a set -x at the top of this script, and this line, while working 
as expected:

if test ${InMail} = "gene"

also spits out this warning:

bin/mailwatcher: line 66: test: =: unary operator expected

What syntax correction does this need?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

perl/bash question - html link out of text

[Vadkan Jozsef]

I don't know how to modify the:

sed -r 's,.*(http://[^ \$]+).*,a href=\\1\\1/a,'

command, to not just:
$ echo test string http://somewhere.uk/ test | sed -r 's,.*(http://[^
\$]+).*,a href=\\1\\1/a,'
a href=http://somewhere.uk/;http://somewhere.uk//a

rather output this:
test string a href=http://somewhere.uk/;http://somewhere.uk//a test


can some perl/bash gods help me? :)


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267981676.2365.83.ca...@ubuntu

Re: perl/bash question - html link out of text

[Kumar Appaiah]

On Sun, Mar 07, 2010 at 06:07:56PM +0100, Vadkan Jozsef wrote:
 I don't know how to modify the:
 
 sed -r 's,.*(http://[^ \$]+).*,a href=\\1\\1/a,'
 
 command, to not just:
 $ echo test string http://somewhere.uk/ test | sed -r 's,.*(http://[^
 \$]+).*,a href=\\1\\1/a,'
 a href=http://somewhere.uk/;http://somewhere.uk//a
 
 rather output this:
 test string a href=http://somewhere.uk/;http://somewhere.uk//a test

How about:

echo test string http://somewhere.uk/ test | sed -r 's,(.*)(http://[^ 
\$]+).*,\1a href=\\2\\2/a,'

HTH.

Kumar
-- 
Whoa...I did a 'zcat /vmlinuz  /dev/audio' and I think I heard God...
-- mikecd on #Linux


signature.asc
Description: Digital signature

Re: perl/bash question - html link out of text

[Kumar Appaiah]

On Sun, Mar 07, 2010 at 11:12:39AM -0600, Kumar Appaiah wrote:
 On Sun, Mar 07, 2010 at 06:07:56PM +0100, Vadkan Jozsef wrote:
  I don't know how to modify the:
  
  sed -r 's,.*(http://[^ \$]+).*,a href=\\1\\1/a,'
  
  command, to not just:
  $ echo test string http://somewhere.uk/ test | sed -r 's,.*(http://[^
  \$]+).*,a href=\\1\\1/a,'
  a href=http://somewhere.uk/;http://somewhere.uk//a
  
  rather output this:
  test string a href=http://somewhere.uk/;http://somewhere.uk//a test
 
 How about:
 
 echo test string http://somewhere.uk/ test | sed -r 's,(.*)(http://[^ 
 \$]+).*,\1a href=\\2\\2/a,'

Rather:

echo test string http://somewhere.uk/ test | sed -r 's,(.*)(http://[^ 
\$]+)(.*),\1a href=\\2\\2/a\3,'

Kumar
-- 
Win95 is not a virus; a virus does something.
-- unknown source


signature.asc
Description: Digital signature

Re: perl/bash question - html link out of text

[Boyd Stephen Smith Jr.]

On Sunday 07 March 2010 11:07:56 Vadkan Jozsef wrote:
 I don't know how to modify the:
 
 sed -r 's,.*(http://[^ \$]+).*,a href=\\1\\1/a,'
 
 command, to not just:
 $ echo test string http://somewhere.uk/ test | sed -r 's,.*(http://[^
 \$]+).*,a href=\\1\\1/a,'
 a href=http://somewhere.uk/;http://somewhere.uk//a
 
 rather output this:
 test string a href=http://somewhere.uk/;http://somewhere.uk//a test

sed -r 's,(http://[^ \$]+),a href=\\1\\1/a,'

maybe?
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: perl or bash question [convert strings in a txt to html links]

[Jari Fredriksson]

On 27.2.2010 19:12, Vadkan Jozsef wrote:
 How can I do that in bash or perl, that I have a txt file, e.g.:
 
 $cat file.txt
 Hi, this is the content of the txt file, that contains links like this:
 http://www.somewhere.it/, and it could contain: http://somewhere.com,
 etc..
 This is the second line, that doesn't contains links..
 ..
 This is the XYZ line, that contains a link: http://www.somewhere.net
 $
 

No regexp but how about the txt2html utility?


-- 
http://www.iki.fi/jarif/

Elves and Dragons! I says to him.  Cabbages and potatoes are better
for you and me.
-- J. R. R. Tolkien



signature.asc
Description: OpenPGP digital signature

perl or bash question [convert strings in a txt to html links]

[Vadkan Jozsef]

How can I do that in bash or perl, that I have a txt file, e.g.:

$cat file.txt
Hi, this is the content of the txt file, that contains links like this:
http://www.somewhere.it/, and it could contain: http://somewhere.com,
etc..
This is the second line, that doesn't contains links..
..
This is the XYZ line, that contains a link: http://www.somewhere.net
$


...ok.. so how could I make a regexp for this?

Turning:

http://website.org
http://www.website.org

to this:

a href=http://website.orghttp://website.org/a
a href=http://www.website.orghttp://www.website.org/a

The solution would be:

sed 'SOMEMAGIC' file.txt  file.html
or
perl 'SOMEBIGMAGIC' file.txt  file.html

:D


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267290722.2365.12.ca...@ubuntu

Re: perl or bash question [convert strings in a txt to html links]

[Kelly Clowers]

On Sat, Feb 27, 2010 at 09:12, Vadkan Jozsef jozsi.avad...@gmail.com wrote:
 How can I do that in bash or perl, that I have a txt file, e.g.:

 $cat file.txt
 Hi, this is the content of the txt file, that contains links like this:
 http://www.somewhere.it/, and it could contain: http://somewhere.com,
 etc..
 This is the second line, that doesn't contains links..
 ..
 This is the XYZ line, that contains a link: http://www.somewhere.net
 $


 ...ok.. so how could I make a regexp for this?

 Turning:

 http://website.org
 http://www.website.org

 to this:

 a href=http://website.orghttp://website.org/a
 a href=http://www.website.orghttp://www.website.org/a

 The solution would be:

 sed 'SOMEMAGIC' file.txt  file.html
 or
 perl 'SOMEBIGMAGIC' file.txt  file.html

You might look at the brand new Bleach python library:
http://coffeeonthekeyboard.com/bleach-html-sanitizer-and-auto-linker-for-django-344/

That post mentions some of the problems of using a pure
regex approach... of course you may know that your text file
will not have any of those problems.


Cheers,
Kelly Clowers


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1840f6971002270952g530d0427kc5f29a648db14...@mail.gmail.com

Re: perl or bash question [convert strings in a txt to html links]

[Tony van der Hoff]

On 27/02/10 17:12, Vadkan Jozsef wrote:

How can I do that in bash or perl, that I have a txt file, e.g.:

$cat file.txt
Hi, this is the content of the txt file, that contains links like this:
http://www.somewhere.it/, and it could contain: http://somewhere.com,
etc..
This is the second line, that doesn't contains links..
..
This is the XYZ line, that contains a link: http://www.somewhere.net
$


...ok.. so how could I make a regexp for this?

Turning:

http://website.org
http://www.website.org

to this:

a href=http://website.orghttp://website.org/a
a href=http://www.website.orghttp://www.website.org/a

The solution would be:

sed 'SOMEMAGIC' file.txt  file.html
or
perl 'SOMEBIGMAGIC' file.txt  file.html



Hmm, hardly on-topic for this list, but doubtless someone will want to 
show off their regex skills.


Just to convince us that you're not asking us to do your homework for 
you, what have you tried so far, wit what results?


--
Tony van der Hoff| mailto:t...@vanderhoff.org
Buckinghamshire, England |


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/4b895829.3070...@vanderhoff.org

Re: Bash question: get output as a variable?

[Mart Frauenlob]

On 04.02.2010 23:09, Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:
 
 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz
 
 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?
 
 Thanks!
 

After reading many of the follow-ups, I'd suggest something like that:

#!/bin/bash

# create the archive local first, as if you use 'tar -v' and redirection
# of stderr, you will also catch (possible) error messages of tar, not
# only a file list.

tar -czf archive.tgz

# now list the content with 'tar -t'.
# that ensures that we work only with files, which are in the archive.
# you can put it into an array, or if that's not save enough (as the
# array could become quite big and consume a lot of memory) redirect
# the output to a file.

array=( $(tar -tf archive.tgz) )

# or
tar -tf archive.tgz  file.list

# now do whatever work with the file list, either from the array or
# from the file.

: ...

Best regards

Mart


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Javier Barroso]

On Fri, Feb 5, 2010 at 7:10 PM, Chris Jackson c.jack...@shadowcat.co.uk wrote:
 Dotan Cohen wrote:

 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

 Thanks!



 Use $() like you do with the date command. You have to redirect stderr back
 to stdout, which means running it in a subshell:


 FILES=$( ( tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k
 $1 | dd of=$(hostname)-$(date +%Y%m%d).tbz ) 21 )

 It may cause unexpected results if there're spaces in the filenames though.

If there are spaces in filenames, you can try:

$ n=0; while read l; do files[n]=$l; ((n++)); done  ((tar -zvcf -
* | openssl  $(hostname)-$(date +%Y%m%d)) 21)

Regards,


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Mart Frauenlob]

On 06.02.2010 14:17, Javier Barroso wrote:
 On Fri, Feb 5, 2010 at 7:10 PM, Chris Jackson c.jack...@shadowcat.co.uk 
 wrote:
 Dotan Cohen wrote:

 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

 Thanks!



 Use $() like you do with the date command. You have to redirect stderr back
 to stdout, which means running it in a subshell:


 FILES=$( ( tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k
 $1 | dd of=$(hostname)-$(date +%Y%m%d).tbz ) 21 )

 It may cause unexpected results if there're spaces in the filenames though.
 
 If there are spaces in filenames, you can try:
 
 $ n=0; while read l; do files[n]=$l; ((n++)); done  ((tar -zvcf -
 * | openssl  $(hostname)-$(date +%Y%m%d)) 21)
 
 Regards,
 
 
Warning:

~# read  (printf %s\n  foo bar )
~# printf '%s'\n' $REPLY
' foo bar '
~# read l  (printf %s\n  foo bar )
~# printf '%s'\n' $l
'foo bar'

read strips of leading and trailing spaces.
use the $REPLY variable to avoid that.

rare conditions of newline in filenames is not covered...

Best regards

Mart



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Mart Frauenlob]

On 06.02.2010 13:39, Mart Frauenlob wrote:
 On 04.02.2010 23:09, Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

 Thanks!

 
 After reading many of the follow-ups, I'd suggest something like that:
 
 #!/bin/bash
 
 # create the archive local first, as if you use 'tar -v' and redirection
 # of stderr, you will also catch (possible) error messages of tar, not
 # only a file list.
 
 tar -czf archive.tgz
 
 # now list the content with 'tar -t'.
 # that ensures that we work only with files, which are in the archive.
 # you can put it into an array, or if that's not save enough (as the
 # array could become quite big and consume a lot of memory) redirect
 # the output to a file.
 

forgot:
oifs=$IFS
IFS='$\n'

 array=( $(tar -tf archive.tgz) )
 
 # or
 tar -tf archive.tgz  file.list
 


If filename contains newline the whole thing still is in trouble though.



-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Mart Frauenlob]

On 06.02.2010 15:43, Mart Frauenlob wrote:
 On 06.02.2010 14:17, Javier Barroso wrote:
 On Fri, Feb 5, 2010 at 7:10 PM, Chris Jackson c.jack...@shadowcat.co.uk 
 wrote:
 Dotan Cohen wrote:

 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

 Thanks!



 Use $() like you do with the date command. You have to redirect stderr back
 to stdout, which means running it in a subshell:


 FILES=$( ( tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k
 $1 | dd of=$(hostname)-$(date +%Y%m%d).tbz ) 21 )

 It may cause unexpected results if there're spaces in the filenames though.

 If there are spaces in filenames, you can try:

 $ n=0; while read l; do files[n]=$l; ((n++)); done  ((tar -zvcf -
 * | openssl  $(hostname)-$(date +%Y%m%d)) 21)

 Regards,


 Warning:
 

[..]

 read strips of leading and trailing spaces.
 use the $REPLY variable to avoid that.

or by:
IFS=$'\n'

while IFS=$'\n'; read l [...] ; do ...

 
 rare conditions of newline in filenames is not covered...

 
 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Alexey Salmin]

On Fri, Feb 5, 2010 at 1:20 PM, Javier Barroso javibarr...@gmail.com wrote:
 On Fri, Feb 5, 2010 at 1:06 AM, Stephen Powell zlinux...@wowway.com wrote:
 On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
 In this case output goes to stderr, so:

 tar -zcvf - * --exclude-from $EXCLUDES 2 /tmp/data$$ | openssl ...

 Is that something you just have to find out by trial and error?
 I checked the man page for tar, and there's nothing in there about
 the -v output being written to stderr.  I'll take your word for it,
 but in the general case, it's hard to tell.  Since stdout and
 stderr both default to the terminal, and since the doc doesn't
 say, how else would you know other than by trial and error?
 If you are using stdout as tar output, including filenames there will
 corrupt that output, so it is logical that in this case filenames goes
 to stderr.

 Sorry my bad english, I hope you understand my opinion


That's true: programs using stdout for data output certainly have to
use stderr as a way to report any additional info.

Alexey


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Ken Teague]

On Thu, Feb 4, 2010 at 2:09 PM, Dotan Cohen dotanco...@gmail.com wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

You probably want to put the data into an array rather than a
variable.  An explanation of how to do so can be found here:
 http://tldp.org/LDP/abs/html/arrays.html

Scroll down to the end of Example 26-7 (just about Example 26-8).
Basically, direct stdout to a file, then cat the file to add it to an
array.

snip
The array=( element1 element2 ... elementN )  initialization
operation, with the help of command substitution, makes it possible to
load the contents of a text file into an array.

#!/bin/bash

filename=sample_file

#cat sample_file
#
#1 a b c
#2 d e fg


declare -a array1

array1=( `cat $filename`)#  Loads contents
# List file to stdout  #+ of $filename into array1.
#
#  array1=( `cat $filename | tr '\n' ' '`)
#change linefeeds in file to spaces.
#  Not necessary because Bash does word splitting,
#+ changing linefeeds to spaces.

echo ${arra...@]}# List the array.
#  1 a b c 2 d e fg
#
#  Each whitespace-separated word in the file
#+ has been assigned to an element of the array.

element_count=${#array1[*]}
echo $element_count  # 8
snip


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[bruno]

Ken Teague wrote:

On Thu, Feb 4, 2010 at 2:09 PM, Dotan Cohen dotanco...@gmail.com wrote:
  

I'm scripting a backup solution, the line that does the business looks
like this:

tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
dd of=$(hostname)-$(date +%Y%m%d).tbz

Because of the v flag tar writes to stdout the name of each file
copied. How can I get that output redirected to a variable, to use
later in the script?



You probably want to put the data into an array rather than a
variable.  An explanation of how to do so can be found here:
 http://tldp.org/LDP/abs/html/arrays.html

Scroll down to the end of Example 26-7 (just about Example 26-8).
Basically, direct stdout to a file, then cat the file to add it to an
array.

snip
The array=( element1 element2 ... elementN )  initialization
operation, with the help of command substitution, makes it possible to
load the contents of a text file into an array.

#!/bin/bash

filename=sample_file

#cat sample_file
#
#1 a b c
#2 d e fg


declare -a array1

array1=( `cat $filename`)#  Loads contents
# List file to stdout  #+ of $filename into array1.
#
#  array1=( `cat $filename | tr '\n' ' '`)
#change linefeeds in file to spaces.
#  Not necessary because Bash does word splitting,
#+ changing linefeeds to spaces.

echo ${arra...@]}# List the array.
#  1 a b c 2 d e fg
#
#  Each whitespace-separated word in the file
#+ has been assigned to an element of the array.

element_count=${#array1[*]}
echo $element_count  # 8
snip


  

Why not simply use the  t option for content listing :

tar tvf  * --exclude-from $EXCLUDES

Bruno



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Mart Frauenlob]

On 05.02.2010 09:07, Ken Teague wrote:
 On Thu, Feb 4, 2010 at 2:09 PM, Dotan Cohen dotanco...@gmail.com wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?
 
 You probably want to put the data into an array rather than a
 variable.  An explanation of how to do so can be found here:
  http://tldp.org/LDP/abs/html/arrays.html
 
 #!/bin/bash

tar ... 2 $filename
mapfile array1  $filename

(don't know actually why '-u 2' option for mapfile does not complete for
me? would make it a 'one-liner'.)

on bash4.0+

regards

Mart


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Stephen Powell]

On Fri, 5 Feb 2010 02:20:48 -0500 (EST), Javier Barroso wrote:
 If you are using stdout as tar output, including filenames there will
 corrupt that output, so it is logical that in this case filenames goes
 to stderr.

That does make sense, now that I think about it.  I didn't look
closely enough.  I saw what I expected to see.  The extracted
files themselves always go to disk.  But they don't in this
case.  Thanks.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Ken Teague]

On Fri, Feb 5, 2010 at 12:39 AM, bruno bruno.deb...@cyberoso.com wrote:
 Why not simply use the  t option for content listing :

 tar tvf  * --exclude-from $EXCLUDES

He's already creating the archive with -v.  Why process the archive a
2nd time just to get a listing when it comes from stdout the 1st time?


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[bruno]

Ken Teague wrote:

On Fri, Feb 5, 2010 at 12:39 AM, bruno bruno.deb...@cyberoso.com wrote:
  

Why not simply use the  t option for content listing :

tar tvf  * --exclude-from $EXCLUDES



He's already creating the archive with -v.  Why process the archive a
2nd time just to get a listing when it comes from stdout the 1st time?


  

because it's a simplier way to get the list into a variable
because the script gets much clearer
because it is not safe to rely on stderr since it is supposed to display 
errors, which it might do as well
because he would get the list of the files that have really been 
compressed, not just the processed ones
because the overhead may not be worth the complication of trying to do 
both things at the same time
because he might as well never use the v option (it's not useful in my 
proposition either, and it would even reduce the overhead)


because it is another way to do it and nobody had proposed it before


Bruno


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Paul E Condon]

On 20100205_135919, Alexey Salmin wrote:
 On Fri, Feb 5, 2010 at 1:20 PM, Javier Barroso javibarr...@gmail.com wrote:
  On Fri, Feb 5, 2010 at 1:06 AM, Stephen Powell zlinux...@wowway.com wrote:
  On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
  In this case output goes to stderr, so:
 
  tar -zcvf - * --exclude-from $EXCLUDES 2 /tmp/data$$ | openssl ...
 
  Is that something you just have to find out by trial and error?
  I checked the man page for tar, and there's nothing in there about
  the -v output being written to stderr. ?I'll take your word for it,
  but in the general case, it's hard to tell. ?Since stdout and
  stderr both default to the terminal, and since the doc doesn't
  say, how else would you know other than by trial and error?
  If you are using stdout as tar output, including filenames there will
  corrupt that output, so it is logical that in this case filenames goes
  to stderr.
 
  Sorry my bad english, I hope you understand my opinion
 
 
 That's true: programs using stdout for data output certainly have to
 use stderr as a way to report any additional info.
 
 Alexey

A comment towards 'how would I know':

Traditional Unix and traditional C both made provision for stdin,
stdout, and stderr. When Stroustrup, et al., started working on C++
and its earlier predicessors, someone recognized the need for a fourth
stdXXX, namely stdlog.  I think it was/is a good idea, but it has
never gained enough traction to justify all the changes that would be
required if it were introduced into the POSIX standard. Instead, the
community has kept the name stderr, but changed the usage to something
that might better be named stdmsg, indicating both errors and action
logging. Its the sort of historical development that doesn't get recorded
in any man page (or at least any man page that newbies know about).

HTH
-- 
Paul E Condon   
pecon...@mesanetworks.net


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

[OT] - Bash question: get output as a variable?

[Stephen Powell]

On Fri, 5 Feb 2010 10:44:28 -0500 (EST), bruno wrote:
 Ken Teague wrote:
 On Fri, Feb 5, 2010 at 12:39 AM, bruno bruno.deb...@cyberoso.com wrote:
   
 Why not simply use the  t option for content listing :

 tar tvf  * --exclude-from $EXCLUDES
 

 He's already creating the archive with -v.  Why process the archive a
 2nd time just to get a listing when it comes from stdout the 1st time?


   
 because it's a simplier way to get the list into a variable
 because the script gets much clearer
 because it is not safe to rely on stderr since it is supposed to display 
 errors, which it might do as well
 because he would get the list of the files that have really been 
 compressed, not just the processed ones
 because the overhead may not be worth the complication of trying to do 
 both things at the same time
 because he might as well never use the v option (it's not useful in my 
 proposition either, and it would even reduce the overhead)

 because it is another way to do it and nobody had proposed it before

This is off topic from the OP's question, but one of the things that I
miss in the Linux environment that I used to use a lot in the CMS
environment is CMS Pipelines.  The shell supports pipelines, but they
are *single-stream* pipelines.  CMS pipelines supports *multi-stream*
pipelines.  That one feature alone makes CMS Pipelines so much more
powerful than shell pipelines.  I wish the shell supported multi-stream
pipelines.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] - Bash question: get output as a variable?

[John Hasler]

Stephen Powell writes:
 I wish the shell supported multi-stream pipelines.

I think you could fake it with tee and a fifo.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] - Bash question: get output as a variable?

[Bob McGowan]

Stephen Powell wrote:
 On Fri, 5 Feb 2010 10:44:28 -0500 (EST), bruno wrote:
 Ken Teague wrote:
 On Fri, Feb 5, 2010 at 12:39 AM, bruno bruno.deb...@cyberoso.com wrote:
   
 Why not simply use the  t option for content listing :

 tar tvf  * --exclude-from $EXCLUDES
 
 He's already creating the archive with -v.  Why process the archive a
 2nd time just to get a listing when it comes from stdout the 1st time?

---because removed---

 
 This is off topic from the OP's question, but one of the things that I
 miss in the Linux environment that I used to use a lot in the CMS
 environment is CMS Pipelines.  The shell supports pipelines, but they
 are *single-stream* pipelines.  CMS pipelines supports *multi-stream*
 pipelines.  That one feature alone makes CMS Pipelines so much more
 powerful than shell pipelines.  I wish the shell supported multi-stream
 pipelines.
 
 

As I'm not familiar with CMS, I have no idea if the following matches or
is completely off target ...

The default pipeline in shells always operates with stdout/stdin, which
is a bit limiting.

But, you can work around it, a bit, like this:

  cat abc_does_not_exist 21 | wc

The 'cat' error message gets sent to wc.  The normal cat output is still
to stdout, so it also would be processed by wc, when the file exists.

The shell also allows you to open your own descriptors to files, using:

  exec 5abc
  date 5
  cat abc
  Fri Feb  5 09:15:15 PST 2010

Or, you can set the descriptor to point to another one:

  exec 51
  date 5
  Fri Feb  5 09:15:15 PST 2010

You can also create named pipes using 'mknod a_name p'.  For example:

  mknod fifo1 p
  mknod fifo2 p
  tr '[A-Z]' '[a-z]'  fifo1 fifo2 
  [1] 25269
  echo ABCDEFG  fifo1
  cat fifo2
  abcdefg
  [1]+  Donetr '[A-Z]' '[a-z]' fifo1 fifo2

Perhaps one or another of the above will do what you want?

-- 
Bob McGowan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Bob McGowan]

Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:
 
 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz
 
 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?
 
 Thanks!
 

I would avoid trying to store the file listing in any type of variable,
since you have no idea how big the list will be.

And, as others have noted, in the above case the file names list is sent
to stderr, so it doesn't mess up the stdout you requested for the
archive data.

I'd recommend using a named pipe, or FIFO, like this:

  mknod filenames p
  tar -zcvf - *  --exclude-from $EXCLUDES 2filenames  |
  openssl ... | dd ... 

NOTE:  the '2filenames' and the ampersand to put the command into the
background.

Then, later in the script, you would do something like this:

while read filename
do
  # other work
done  filenames

I've not done the above with anything large enough to know, but the way
a FIFO works, the read loop will block, waiting for input, if it
exhausts the FIFO content.  The FIFO will generate a zero length read
after the last line from tar is captured which will terminate the loop.

-- 
Bob McGowan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Bob McGowan]

Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:
 
 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz
 
 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?
 
 Thanks!
 

I forgot to ask, in the last post:  Why are you using the 'dd' command?

I would think you could do:

  tar ... | openssl ...  $(hostname)-$(date +%Y%m%d).tbz

-- 
Bob McGowan
Symantec
US Internationalization


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] - Bash question: get output as a variable?

[Stephen Powell]

On Fri, 5 Feb 2010 11:39:26 -0500 (EST), John Hasler wrote:
 Stephen Powell writes:
 I wish the shell supported multi-stream pipelines.

 I think you could fake it with tee and a fifo.

Well, I know about tee; but, although I've heard the term fifo,
I know nothing about it in a Linux/Unix/shell context.  I'll look
into it.  Thanks.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Chris Jackson]

Dotan Cohen wrote:


I'm scripting a backup solution, the line that does the business looks
like this:

tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
dd of=$(hostname)-$(date +%Y%m%d).tbz

Because of the v flag tar writes to stdout the name of each file
copied. How can I get that output redirected to a variable, to use
later in the script?

Thanks!




Use $() like you do with the date command. You have to redirect stderr 
back to stdout, which means running it in a subshell:



FILES=$( ( tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt 
-k $1 | dd of=$(hostname)-$(date +%Y%m%d).tbz ) 21 )


It may cause unexpected results if there're spaces in the filenames though.

--
Chris Jackson
Shadowcat Systems Ltd.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Boyd Stephen Smith Jr.]

On Friday 05 February 2010 10:01:45 Paul E Condon wrote:
 Traditional Unix and traditional C both made provision for stdin,
 stdout, and stderr. When Stroustrup, et al., started working on C++
 and its earlier predicessors, someone recognized the need for a fourth
 stdXXX, namely stdlog.

If you system provides stdlog (or a C++ equivalent), it is likely still file 
descriptor 2, but opened in line-buffered mode.  stderr (and cerr) is supposed 
to be opened in non-buffered mode.
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: Bash question: get output as a variable?

[Brian Ryans]

Quoting Stephen Powell on 2010-02-04 18:06:58:
 but in the general case, it's hard to tell.  Since stdout and
 stderr both default to the terminal, and since the doc doesn't
 say, how else would you know other than by trial and error?

Trial and error is an effective way to figure it out. [1] Depending on a
few factors though, it may be more instructive long-term to read the
source. I've recently been putting that philosophy to use in various
things where the documentation's not quite clear. Both methods have
their merits.

[1] possibly redirect std{out,err} to separate temp files and view them?

-- 
 _  Brian Ryans 8B2A 54C4 E275 8CFD 8A7D 5D0B 0AD0 B014 C112 13D0 .
( ) ICQ UIN: 43190205 | Mail/MSN/Jabber: brianlry...@gmail.com   ..:
 X  ASCII Ribbon Campaign Against HTML mail and v-cards: asciiribbon.org
/ \ Any technology distinguishable from magic is insufficently advanced.


signature.asc
Description: Digital signature

Re: [OT] - Bash question: get output as a variable?

[Stephen Powell]

On Fri, 5 Feb 2010 12:42:47 -0500 (EST), Bob McGowan wrote:
 Stephen Powell wrote:
 This is off topic from the OP's question, but one of the things that I
 miss in the Linux environment that I used to use a lot in the CMS
 environment is CMS Pipelines.  The shell supports pipelines, but they
 are *single-stream* pipelines.  CMS pipelines supports *multi-stream*
 pipelines.  That one feature alone makes CMS Pipelines so much more
 powerful than shell pipelines.  I wish the shell supported multi-stream
 pipelines.
 
 As I'm not familiar with CMS, I have no idea if the following matches or
 is completely off target ...
 
 The default pipeline in shells always operates with stdout/stdin, which
 is a bit limiting.

 But, you can work around it, a bit, like this:

  cat abc_does_not_exist 21 | wc

 The 'cat' error message gets sent to wc.  The normal cat output is still
 to stdout, so it also would be processed by wc, when the file exists.
 
 The shell also allows you to open your own descriptors to files, using:

  exec 5abc
  date 5
  cat abc
  Fri Feb  5 09:15:15 PST 2010

 Or, you can set the descriptor to point to another one:

  exec 51
  date 5
  Fri Feb  5 09:15:15 PST 2010

 You can also create named pipes using 'mknod a_name p'.  For example:

  mknod fifo1 p
  mknod fifo2 p
  tr '[A-Z]' '[a-z]'  fifo1 fifo2 
  [1] 25269
  echo ABCDEFG  fifo1
  cat fifo2
  abcdefg
  [1]+  Donetr '[A-Z]' '[a-z]' fifo1 fifo2

 Perhaps one or another of the above will do what you want?

These are all helpful tips and tricks, and I'll keep them
in mind.  I really won't know if I can do the kind of things
I want with these until I try, I suppose.  I don't have a
specific application in mind right now.  Let me give you a
simple example of a CMS pipeline for illustrative purposes,
so that you will get some idea of what I'm talking about.

This is a REXX EXEC (i.e. a script written in the REXX
interpretive language) designed to run on the CMS operating
system running in a virtual machine under z/VM:

--

'PIPE (ENDCHAR ?)',/* Declare pipeline endchar. */
   '   USER DIRECT|', /* Read directory file.  */
   '  NFIND *|',   /* Discard comments. */
   'LOCM: LOCATE /MDISK/|',/* Select MDISK records  */
   'FIN:  FANINANY|',  /* Collect MDISKs and LINKs. */
   '   OUTPUT FILE A',/* Write them to a file. */
   '?',/* End of stream.*/
   'LOCM: |',  /* Non-MDISK cards to here   */
   '  LOCATE /LINK/|', /* Select LINK cards.*/
   'FIN:'  /* Send them to faninany.*/
   /* End of stream and pipe*/
 
--

This is all one command, as viewed by the REXX interpreter.
The stuff between /* and */ are comments.  They are ignored
by the interpreter.  Note that all lines end in a comma,
which is the continuation character, except the last.  The
vertical bar, as with shell pipelines, is the stage separator.
The apostrophes serve as quote characters, just as in the shell.
PIPE is the name of the command to invoke.  The rest of the
stuff is just arguments to the PIPE command.  In other words,
the REXX interpreter itself has no concept of a pipeline.
It is just passing a string of characters to a CMS command
called PIPE.  It is the PIPE command that understands what
a pipeline is.  The question mark is defined as an
end-of-stream character.  It marks the end of a section of
pipe, if you will.

The pipe consists of a number of stages.  The stage numbers
and their names are as follows:

   1. 
   2. NFIND
   3. LOCATE
   4. FANINANY
   5. 
   6. LOCATE

Don't be confused by  and .  They are not redirection
operators.  There's no such thing as a redirection operator
in REXX or in CMS Pipelines.   and  are the names of
stages, just like the others.  Stage 2 and stage 6 are two
different instances of the LOCATE stage.  They have separate
inputs and outputs.  LOCM and FIN are labels.  They are
names given to some of the stages so that they can be
referenced later.  You can tell they are labels because they
end with a colon.

Stage 1, , reads records (lines) from a file, the name
of which is USER DIRECT *.  (The asterisk, meaning on the
first accessed disk you can find it on is implied by default.)
Input stream 1 is unconnected
and not used, since it is the first stage.  Records from
the file are written to output stream 1.

Stage 2, NFIND, has its input stream 1 connected to output stream
1 of stage 1.  Records which do not begin with an asterisk
in column 1 are written to output stream 1.  Records which
do begin with an asterisk are written to output stream 2,
if it is connected.  Otherwise, they are discarded.
Since output stream 2 is not connected, they are discarded.

Stage 3, LOCATE, has its input stream 1 connected to output
stream 1 of stage 2.  Records containing the character string
MDISK are written to output stream 

Re: [OT] - Bash question: get output as a variable?

[Boyd Stephen Smith Jr.]

On Friday 05 February 2010 14:47:21 Stephen Powell wrote:
 On Fri, 5 Feb 2010 12:42:47 -0500 (EST), Bob McGowan wrote:
 Let me give you a
 simple example of a CMS pipeline for illustrative purposes,
 so that you will get some idea of what I'm talking about.
 

[snip: Long, but very useful description.]

 This pipeline can be illustrated graphically as follows:
 
   +---+   +---+   ++   +--+   +---+
 |-|  |--| NFIND |--| LOCATE |--| FANINANY |--|  |-|
   +---+   +---+   ++ 1   1 +--+   +---+
   | 2| 2
   V  A
   |++|
LOCM:--| LOCATE |---FIN:
++

mkfifo LOCM 
mkfifo FIN 
(
 | NFIND | LOCATE 2 LOCM | FANINANY 2 FIN|  
LOCATE  LOCM  FIN 
wait
)

People with more shell magic than me might be able to simplify that to not use 
fifos, but I figured they were fair game since you get stream labels.  (That's 
basically all a fifo is.)

Technically speaking, that's all one command, per the Single UNIX Specifation.  
It matches the shell grammar start symbol complete_command documented 
http://www.opengroup.org/onlinepubs/007908775/xcu/chap2.html#tag_001_010_002.

So, basically, we have different basic building blocks (I don't know a grep 
variant that acts like LOCATE, for example), but the larger structure is very 
similar.

Most UNIX/Linux utilities for the command line assume all input on fd 0, all 
normal output on fd 1, and end-user notifications written to fd 2.  However, 
there's nothing actively preventing binaries from reading from fd 2, writing 
to fd 0, or expecting i/o on fds 3 through 9.  (IIRC, anything greater than 9 
is reserved when using the shell.)
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: [OT] - Bash question: get output as a variable?

[Bob McGowan]

Boyd Stephen Smith Jr. wrote:
 On Friday 05 February 2010 14:47:21 Stephen Powell wrote:
 On Fri, 5 Feb 2010 12:42:47 -0500 (EST), Bob McGowan wrote:
 Let me give you a
 simple example of a CMS pipeline for illustrative purposes,
 so that you will get some idea of what I'm talking about.

 
 [snip: Long, but very useful description.]
 
 This pipeline can be illustrated graphically as follows:

   +---+   +---+   ++   +--+   +---+
 |-|  |--| NFIND |--| LOCATE |--| FANINANY |--|  |-|
   +---+   +---+   ++ 1   1 +--+   +---+
   | 2| 2
   V  A
   |++|
LOCM:--| LOCATE |---FIN:
++
 
 mkfifo LOCM 
 mkfifo FIN 
 (
| NFIND | LOCATE 2 LOCM | FANINANY 2 FIN|  
   LOCATE  LOCM  FIN 
   wait
 )
 
 People with more shell magic than me might be able to simplify that to not 
 use 
 fifos, but I figured they were fair game since you get stream labels.  
 (That's 
 basically all a fifo is.)

I believe the use of fifo's in this context is required.  Unless you're
willing to write the 'LOCATE' and 'FANINANY' tools first, to deal with
inputs on descriptors other than 0, 1 and 2.

Not something I'd care to do, personally. ;)

You might be able to do this using 'exec' to open and redirect the I/O
streams at the shell level, but the nature of the '|' in UNIX/Linux is
to read stdin and write stdout, so everything would need to ultimately
go through those two descriptors, which would disallow having the
parallel processing implied by the above diagram.

 
 Technically speaking, that's all one command, per the Single UNIX 
 Specifation.  
 It matches the shell grammar start symbol complete_command documented 
 http://www.opengroup.org/onlinepubs/007908775/xcu/chap2.html#tag_001_010_002.
 
 So, basically, we have different basic building blocks (I don't know a grep 
 variant that acts like LOCATE, for example), but the larger structure is very 
 similar.
 
 Most UNIX/Linux utilities for the command line assume all input on fd 0, all 
 normal output on fd 1, and end-user notifications written to fd 2.  However, 
 there's nothing actively preventing binaries from reading from fd 2, writing 
 to fd 0, or expecting i/o on fds 3 through 9.  (IIRC, anything greater than 9 
 is reserved when using the shell.)

-- 
Bob McGowan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] - Bash question: get output as a variable?

[Boyd Stephen Smith Jr.]

On Friday 05 February 2010 16:33:12 Bob McGowan wrote:
 Boyd Stephen Smith Jr. wrote:
  mkfifo LOCM 
  mkfifo FIN 
  (
   | NFIND | LOCATE 2 LOCM | FANINANY 2 FIN|  
  LOCATE  LOCM  FIN 
  wait
  )
 
 which would disallow having the
 parallel processing implied by the above diagram.

My example runs in parallel.  It's virtually required when using fifos.  They 
aren't normal files -- only so much data can be written to their internal 
buffer before further writes block.

In this case the shell actually starts at least 6 processes.  One for each 
utility.  Prior to doing the exec call in each process, it sets up the 
pipes and redirection.  It doesn't wait for the processes to finish (notice 
the '' at the end of the pipelines) until I use the wait shell-builtin.

When the LOCATE utility on the second line starts trying to read from stdin 
(LOCM) it will block until the LOCATE utility on the second line writes data 
to stderr (LOCM) and more-or-less immediately start working on that data as 
soon as it arrives.  Similarly, FANINMANY will block when trying to read 
stderr (FIN) just until the LOCATE on the second line writes data out to 
stdout (FIN).
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net  ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: [OT] - Bash question: get output as a variable?

[Bob McGowan]

Boyd Stephen Smith Jr. wrote:
 On Friday 05 February 2010 16:33:12 Bob McGowan wrote:
 Boyd Stephen Smith Jr. wrote:
 mkfifo LOCM 
 mkfifo FIN 
 (
  | NFIND | LOCATE 2 LOCM | FANINANY 2 FIN|  
 LOCATE  LOCM  FIN 
 wait
 )
 which would disallow having the
 parallel processing implied by the above diagram.
 
 My example runs in parallel.  It's virtually required when using fifos.  They 
 aren't normal files -- only so much data can be written to their internal 
 buffer before further writes block.
 
 In this case the shell actually starts at least 6 processes.  One for each 
 utility.  Prior to doing the exec call in each process, it sets up the 
 pipes and redirection.  It doesn't wait for the processes to finish (notice 
 the '' at the end of the pipelines) until I use the wait shell-builtin.
 
 When the LOCATE utility on the second line starts trying to read from stdin 
 (LOCM) it will block until the LOCATE utility on the second line writes 
 data 
 to stderr (LOCM) and more-or-less immediately start working on that data as 
 soon as it arrives.  Similarly, FANINMANY will block when trying to read 
 stderr (FIN) just until the LOCATE on the second line writes data out to 
 stdout (FIN).

My point, exactly, though better said ;)

If someone wanted to, they could write a single program that would read
input/write output from/to two or more descriptors, and use it to create
a multi-path'ed I/O processing sequence, but writing it to prevent
blocking on one input/output, so it could continue working on the other
pair, would be a bit hairy.

The fifo node makes this sort of thing easy to do.

-- 
Bob McGowan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Ken Teague]

On Fri, Feb 5, 2010 at 7:44 AM, bruno bruno.deb...@cyberoso.com wrote:
 because it's a simplier way to get the list into a variable

Can you please explain how it's simpler.  The method I suggested
certainly isn't as easy, but the method I suggested merely showed a
detailed example.  Others here are coming up with 1 or 2 liners that
can do this without having to process the archive a 2nd time.

I don't see how the example you provided puts the list into a
variable.  Would you be so kind as to go into more detail regarding
your suggestion?


 because the script gets much clearer

I agree that your suggestion would be much clearer, and your
suggestion may suit the needs of the OP.  I suppose it's just my
personal feelings to not sacrifice efficiency for making a script
easier to understand.  Comments can be added to the script to explain
how parts of it function.


 because it is not safe to rely on stderr since it is supposed to display
 errors, which it might do as well

Others have recommended stderr.  I'm not sure why.  The method that
would be most effective would be to direct stdout, not stderr.

it...@mybox:~$ ls -l
-rw-r--r-- 1 itsme itsme 0 2010-02-05 14:54 file1
-rw-r--r-- 1 itsme itsme 0 2010-02-05 14:54 file2
-rw-r--r-- 1 itsme itsme 0 2010-02-05 14:54 file3
-rw--- 1 root   root0 2010-02-05 14:53 somefile
it...@mybox:~$ tar cvf test.tar somefile file1 file2 file3 out.txt
tar: somefile: Cannot open: Permission denied
tar: Error exit delayed from previous errors
it...@mybox:~$ cat out.txt
file1
file2
file3


 because he would get the list of the files that have really been compressed,
 not just the processed ones

Not if he uses stdout.  The example shown above only shows what was
added to the tar file.


 because the overhead may not be worth the complication of trying to do both
 things at the same time

Efficiency vs clarity; sometimes it's a personal preference, other
times it may not be.  For example, if I'm passing this script on to
someone else that isn't familiar with the scripting language, I think
clarity would be paramount.  Otherwise, I'd go for efficiency.


 because he might as well never use the v option (it's not useful in my
 proposition either, and it would even reduce the overhead)

The method you suggested is to process the archive a 2nd time to get
the listing, and to use -tv.  That causes more overhead than getting
the list of processed files while the archive is being created.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Ken Teague]

On Fri, Feb 5, 2010 at 10:10 AM, Chris Jackson
c.jack...@shadowcat.co.uk wrote:
 Use $() like you do with the date command. You have to redirect stderr back
 to stdout, which means running it in a subshell:


 FILES=$( ( tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k
 $1 | dd of=$(hostname)-$(date +%Y%m%d).tbz ) 21 )

 It may cause unexpected results if there're spaces in the filenames though.

I think this is the best method I've seen thus far.  Putting the data
into an array should avoid problems with file names containing spaces.
 I don't understand why he would stderr in it, though.  I'd like to
know what the OP plans to do with the list of processed files.


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Tony Nelson]

On 10-02-04 19:06:58, Stephen Powell wrote:
 On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
  In this case output goes to stderr, so:
  
  tar -zcvf - * --exclude-from $EXCLUDES 2 /tmp/data$$ | openssl ...
 
 Is that something you just have to find out by trial and error?
 I checked the man page for tar, and there's nothing in there about
 the -v output being written to stderr.  I'll take your word for it,
 but in the general case, it's hard to tell.  Since stdout and
 stderr both default to the terminal, and since the doc doesn't
 say, how else would you know other than by trial and error?

As the man page notes, see `info tar`.  The answer is buried in 3.9 
Asking for Confirmation During Operations.

-- 

TonyN.:'   mailto:tonynel...@georgeanelson.com
  '  http://www.georgeanelson.com/


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Ken Teague]

On Fri, Feb 5, 2010 at 12:42 AM, Mart Frauenlob
mart.frauen...@chello.at wrote:
 tar ... 2 $filename
 mapfile array1  $filename

 (don't know actually why '-u 2' option for mapfile does not complete for
 me? would make it a 'one-liner'.)

 on bash4.0+


This is a great example as well.  The only problem is bash4 isn't
readily available to people using lenny.  Also, wouldn't he just want
to redirect sdtout and not stderr?  I guess it all depends on what he
wants to do with the list.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Bob McGowan]

Ken Teague wrote:
 On Fri, Feb 5, 2010 at 10:10 AM, Chris Jackson
 c.jack...@shadowcat.co.uk wrote:
 Use $() like you do with the date command. You have to redirect stderr back
 to stdout, which means running it in a subshell:


 FILES=$( ( tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k
 $1 | dd of=$(hostname)-$(date +%Y%m%d).tbz ) 21 )

 It may cause unexpected results if there're spaces in the filenames though.
 
 I think this is the best method I've seen thus far.  Putting the data
 into an array should avoid problems with file names containing spaces.
  I don't understand why he would stderr in it, though.  I'd like to
 know what the OP plans to do with the list of processed files.
 
 

As noted in some earlier posts, using 'tar -f -' causes the archive tar
creates to be written to stdout.

This means the list of file names printed because of the 'v' option,
must be written to some other file descriptor, else it will corrupt the
archive contents.

The usual way for an app to do this is to write to stderr, which is
what 'tar' does.

The tar sdtout is already redirected in the initial pipeline.  Putting
the pipeline in parenthesis causes the entire thing to run in a
subshell.  The '21' takes the stderr of the subshell and puts it onto
the stdout of the current shell, which is then redirected by the $(...)
into the variable.

-- 
Bob McGowan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: [OT] - Bash question: get output as a variable?

[Stephen Powell]

On Fri, 5 Feb 2010 18:27:49 -0500 (EST), Bob McGowan wrote:
 If someone wanted to, they could write a single program that would read
 input/write output from/to two or more descriptors, and use it to create
 a multi-path'ed I/O processing sequence, but writing it to prevent
 blocking on one input/output, so it could continue working on the other
 pair, would be a bit hairy.
 
 The fifo node makes this sort of thing easy to do.

Well, as Mr. Spock would say,

   Fascinating!

It appears that the combination of a shell pipeline and
fifos makes the implementation of a multi-streamed pipeline
possible.  The problem is the lack of stages,
especially the stream splitting and stream joining ones.

Thank you, Bob and Boyd, for your insights and expertise.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bash question: get output as a variable?

[Dotan Cohen]

I'm scripting a backup solution, the line that does the business looks
like this:

tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
dd of=$(hostname)-$(date +%Y%m%d).tbz

Because of the v flag tar writes to stdout the name of each file
copied. How can I get that output redirected to a variable, to use
later in the script?

Thanks!

-- 
Dotan Cohen

http://what-is-what.com
http://gibberish.co.il

Please CC me if you want to be sure that I read your message. I do not
read all list mail.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Alex Samad]

On Fri, Feb 05, 2010 at 12:09:28AM +0200, Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:
 
 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz
 
 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

not sure you can, as you are pushing the tar output via stdout as well.
maybe use a fifo to communicate between tar and openssl

Alex

 
 Thanks!
 

-- 
Winter is the season in which people try to keep the house as warm as
it was in the summer, when they complained about the heat.


signature.asc
Description: Digital signature

Re: Bash question: get output as a variable?

[Stephen Powell]

On Thu, 4 Feb 2010 17:09:28 -0500 (EST), Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:
 
 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz
 
 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

First of all, let me preface my remarks by saying that I am just
learning shell scripting myself and definitely consider myself a
novice.  Some guru out there may (and probably does) know a better
way.

Using a variable is problematic, since a pipeline runs in a subshell
environment.  In fact, each stage of the pipeline is a separate
process.  Thus, any variables set in a pipeline stage do not
affect the values of the corresponding variable names in the shell
environment that invoked the pipeline.

How about something like this?

   tar -zcvf - * --exclude-from $EXCLUDES | tee /tmp/data$$ | \
   openssl ...
   .
   . logic to process the /tmp/data$$ data file
   .
   rm /tmp/data$$
 


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Javier Barroso]

On Thu, Feb 4, 2010 at 11:32 PM, Stephen Powell zlinux...@wowway.com wrote:
 On Thu, 4 Feb 2010 17:09:28 -0500 (EST), Dotan Cohen wrote:
 I'm scripting a backup solution, the line that does the business looks
 like this:

 tar -zcvf - *  --exclude-from $EXCLUDES  | openssl des3 -salt -k $1 |
 dd of=$(hostname)-$(date +%Y%m%d).tbz

 Because of the v flag tar writes to stdout the name of each file
 copied. How can I get that output redirected to a variable, to use
 later in the script?

 First of all, let me preface my remarks by saying that I am just
 learning shell scripting myself and definitely consider myself a
 novice.  Some guru out there may (and probably does) know a better
 way.

 Using a variable is problematic, since a pipeline runs in a subshell
 environment.  In fact, each stage of the pipeline is a separate
 process.  Thus, any variables set in a pipeline stage do not
 affect the values of the corresponding variable names in the shell
 environment that invoked the pipeline.

 How about something like this?

   tar -zcvf - * --exclude-from $EXCLUDES | tee /tmp/data$$ | \
   openssl ...
In this case output goes to stderr, so:

tar -zcvf - * --exclude-from $EXCLUDES 2 /tmp/data$$ | openssl ...


   .
   . logic to process the /tmp/data$$ data file
   .
   rm /tmp/data$$



 --
 To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org




--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Stephen Powell]

On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
 In this case output goes to stderr, so:
 
 tar -zcvf - * --exclude-from $EXCLUDES 2 /tmp/data$$ | openssl ...

Is that something you just have to find out by trial and error?
I checked the man page for tar, and there's nothing in there about
the -v output being written to stderr.  I'll take your word for it,
but in the general case, it's hard to tell.  Since stdout and
stderr both default to the terminal, and since the doc doesn't
say, how else would you know other than by trial and error?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Bash question: get output as a variable?

[Javier Barroso]

On Fri, Feb 5, 2010 at 1:06 AM, Stephen Powell zlinux...@wowway.com wrote:
 On Thu, 4 Feb 2010 17:42:45 -0500 (EST), Javier Barroso wrote:
 In this case output goes to stderr, so:

 tar -zcvf - * --exclude-from $EXCLUDES 2 /tmp/data$$ | openssl ...

 Is that something you just have to find out by trial and error?
 I checked the man page for tar, and there's nothing in there about
 the -v output being written to stderr.  I'll take your word for it,
 but in the general case, it's hard to tell.  Since stdout and
 stderr both default to the terminal, and since the doc doesn't
 say, how else would you know other than by trial and error?
If you are using stdout as tar output, including filenames there will
corrupt that output, so it is logical that in this case filenames goes
to stderr.

Sorry my bad english, I hope you understand my opinion


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: bash question

[Boyd Stephen Smith Jr.]

In 20091010042217.gd2...@samad.com.au, Alex Samad wrote:
Hi

i have this

RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C  %s
rdiff-backup  --server'


and trying this

rdiff-backup \
   $RDSCHM \
   $RDRM \
   $DEST/

Sorry, there's no clean, portable way to have both multiple command-line 
arguments in a single variable and have an IFS character in one of those 
arguments.

When you do this rdiff-backup gets these arguments:
argv = {
 [0] = rdiff-backup
 [1] = --remote-schema
 [2] = 'ssh
 [3] = -i
 [4] = /root/.ssh/id_backup
 [5] = -C
 ... /* etc. */
}

If you force your script to be executed with bash (NOT dash or just sh) you 
can use shell arrays to do what you want:

RDSCHM=(
 '--remote-schema'
 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup --server'
)

rdiff-backup \
$rdsc...@] \
$RDRM \
$DEST/


You can also force your to work correctly under dash / sh, but you'll have to 
understand how to use eval, which can get a bit tricky.  It would look 
something like this:

RDSCHM=--remote-schema \
'ssh -i /root/.ssh/id_backup -C %s rdiff-backup --server'

eval rdiff-backup $RDSCHM $RDRM '$DEST/'
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a digitally signed message part.

Re: bash question

[Alex Samad]

On Sat, Oct 10, 2009 at 01:21:30AM -0500, Boyd Stephen Smith Jr. wrote:
 In 20091010042217.gd2...@samad.com.au, Alex Samad wrote:
 Hi
 
 i have this
 
 RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C  %s
 rdiff-backup  --server'
 
 
 and trying this
 
 rdiff-backup \
  $RDSCHM \
  $RDRM \
  $DEST/
 
 Sorry, there's no clean, portable way to have both multiple command-line 
 arguments in a single variable and have an IFS character in one of those 
 arguments.

Oh well, time to play with IFS or eval

 
 When you do this rdiff-backup gets these arguments:
 argv = {
  [0] = rdiff-backup
  [1] = --remote-schema
  [2] = 'ssh
  [3] = -i
  [4] = /root/.ssh/id_backup
  [5] = -C
  ... /* etc. */
 }
 
 If you force your script to be executed with bash (NOT dash or just sh) you 
 can use shell arrays to do what you want:
 
 RDSCHM=(
  '--remote-schema'
  'ssh -i /root/.ssh/id_backup -C %s rdiff-backup --server'
 )
 
 rdiff-backup \
   $rdsc...@] \
   $RDRM \
   $DEST/
 
 
 You can also force your to work correctly under dash / sh, but you'll have to 
 understand how to use eval, which can get a bit tricky.  It would look 
 something like this:


I wanted to try and stick to non bashisms

 
 RDSCHM=--remote-schema \
 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup --server'
 
 eval rdiff-backup $RDSCHM $RDRM '$DEST/'

thanks

-- 
We're concerned about AIDS inside our White House -- make no mistake about it.

- George W. Bush
02/07/2001


signature.asc
Description: Digital signature

Re: bash question

[Antonio Perez]

Alex Samad wrote:

 Hi, i have this:

 RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C  %s rdiff-backup 
 --server'

 and trying this
 
 rdiff-backup \
 $RDSCHM \
 $RDRM \
 $DEST/

 with sh -x i get this
 
 + rdiff-backup --remote-schema ''\''ssh' -i /root/.ssh/id_backup -C %s 
 rdiff-backup '--server'\''' --remove-older-than '10B' --force 
 max::/backups/test/system/

I am pretty sure you are using bash as the sh link, do 'ls -la /bin/sh' to get: 
/bin/sh -- /bin/bash
If it were dash the responses would be different.

Testing: set up a test file with:
#!/bin/sh
RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'
echo $RDSCHM
echo $RDSCHM
with: bash -x test, I get:
+ RDSCHM='--remote-schema '\''ssh -i /root/.ssh/id_backup -C %s 
rdiff-backup --server'\'''
+ echo --remote-schema ''\''ssh' -i /root/.ssh/id_backup 
$'-C\302\240%s' 'rdiff-backup --server'\'''
--remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'
+ echo '--remote-schema '\''ssh -i /root/.ssh/id_backup -C %s 
rdiff-backup --server'\'''
--remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'

with: dash -x test, I get:
+ RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C %s 
rdiff-backup --server'
+ echo --remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'
--remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'
+ echo --remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'
--remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
--server'

with dash there is no «  ''\''ssh'  »

Also, did you notice the difference between a command on an unquoted variable 
and a quoted one?
+ echo --remote-schema ''\''ssh' -i /root/.ssh/id_backup 
$'-C\302\240%s' 'rdiff-backup --server'\'''
+ echo '--remote-schema '\''ssh -i /root/.ssh/id_backup -C %s 
rdiff-backup --server'\'''

Conclusion: Quoting the variable will solve your problem, as this:
rdiff-backup \
  $RDSCHM \
  $RDRM \
  $DEST/


 the ''\''ssh' is the confusing bit it is seperate out the ssh and the -i.

Yes, on a bash shell, but only while quoting with -x, the actual command does 
the right thing.

 what can I do to prevent this.

Just put « $RDSCHM »  inside quotes as this: « $RDSCHM »

 My reading has lead me to IFS variable
 but I don't want to start playing with this yet ! I think I am just
 missing something. Hopefully the ml eyes will be able to see what i
 can't

No need to

 oh and its using dash well sh

It does not really matter which shell it is, when the issue is about correct 
quoting of variables.

-- 
Antonio Perez


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: bash question

[green]

Boyd Stephen Smith Jr. wrote at 2009-10-10 01:21 -0500:
 You can also force your to work correctly under dash / sh, but you'll have to 
 understand how to use eval, which can get a bit tricky.  It would look 
 something like this:

I second the eval suggestion, it has helped me several times to simplify things 
like this.


signature.asc
Description: Digital signature

Re: bash question

[Alex Samad]

On Sat, Oct 10, 2009 at 07:45:14AM -0400, Antonio Perez wrote:
 Alex Samad wrote:
 
  Hi, i have this:
 
  RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C  %s rdiff-backup 
  --server'
 
  and trying this
  
  rdiff-backup \
  $RDSCHM \
  $RDRM \
  $DEST/
 
  with sh -x i get this
  
  + rdiff-backup --remote-schema ''\''ssh' -i /root/.ssh/id_backup -C %s 
  rdiff-backup '--server'\''' --remove-older-than '10B' --force 
  max::/backups/test/system/
 
 I am pretty sure you are using bash as the sh link, do 'ls -la /bin/sh' to 
 get: /bin/sh -- /bin/bash
 If it were dash the responses would be different.

true - I could have sworn I had installed the latest dash package which
moves sh to dash
 
 Testing: set up a test file with:
 #!/bin/sh
 RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'
 echo $RDSCHM
 echo $RDSCHM
 with: bash -x test, I get:
 + RDSCHM='--remote-schema '\''ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'\'''
 + echo --remote-schema ''\''ssh' -i /root/.ssh/id_backup 
 $'-C\302\240%s' 'rdiff-backup --server'\'''
 --remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
 --server'
 + echo '--remote-schema '\''ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'\'''
 --remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
 --server'
 
 with: dash -x test, I get:
 + RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'
 + echo --remote-schema 'ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'
 --remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
 --server'
 + echo --remote-schema 'ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'
 --remote-schema 'ssh -i /root/.ssh/id_backup -C %s rdiff-backup 
 --server'
 
 with dash there is no «  ''\''ssh'  »
 
 Also, did you notice the difference between a command on an unquoted variable 
 and a quoted one?
 + echo --remote-schema ''\''ssh' -i /root/.ssh/id_backup 
 $'-C\302\240%s' 'rdiff-backup --server'\'''
 + echo '--remote-schema '\''ssh -i /root/.ssh/id_backup -C %s 
 rdiff-backup --server'\'''
 
 Conclusion: Quoting the variable will solve your problem, as this:
 rdiff-backup \
   $RDSCHM \
   $RDRM \
   $DEST/

I tried this but then rdiff-backup tried to execute the whole variable
as 1 command and not such command ssh\ -i\ /roo.

 
 
  the ''\''ssh' is the confusing bit it is seperate out the ssh and the -i.
 
 Yes, on a bash shell, but only while quoting with -x, the actual command does 
 the right thing.
 
  what can I do to prevent this.
 
 Just put « $RDSCHM »  inside quotes as this: « $RDSCHM »
 
  My reading has lead me to IFS variable
  but I don't want to start playing with this yet ! I think I am just
  missing something. Hopefully the ml eyes will be able to see what i
  can't
 
 No need to
 
  oh and its using dash well sh
 
 It does not really matter which shell it is, when the issue is about correct 
 quoting of variables.

Thanks I will investigate more

 



signature.asc
Description: Digital signature

bash question

[Alex Samad]

Hi

i have this 

RDSCHM=--remote-schema 'ssh -i /root/.ssh/id_backup -C  %s
rdiff-backup  --server'


and trying this

rdiff-backup \
$RDSCHM \
$RDRM \
$DEST/


with sh -x i get this

+ rdiff-backup --remote-schema ''\''ssh' -i /root/.ssh/id_backup -C %s
rdiff-backup '--server'\''' --remove-older-than '10B' --force
max::/backups/test/system/
Fatal Error: Bad commandline options: option -i not recognized
See the rdiff-backup manual page for more information.


the ''\''ssh' is the confusing bit it is seperate out the ssh and the
-i.

what can I do to prevent this.  My reading has lead me to IFS variable
but I don't want to start playing with this yet ! I think I am just
missing something. Hopefully the ml eyes will be able to see what i
can't


oh and its using dash well sh

thank

Alex


signature.asc
Description: Digital signature

Re: Probably very stupid script/bash question

[Michelle Konzack]

Am 2008-03-05 14:13:33, schrieb Brian:
 teststring=one two three four five six 
 { read A B C D E F; }  ( echo $teststring ) 
 echo Data received = $E Bytes 
 END OF REPLIED MESSAGE 

This look a little bit weird. Why not use:

8
read A B C D E F EOF
one two three four five six
EOF
8

and

8
teststring=one two three four five six 

read A B C D E F EOF
$teststring
EOF

echo Data received = $E Bytes 
8

no need for a stupid resources eating subschell expecialy on a ARM.

:-)


Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Probably very stupid script/bash question

[Michelle Konzack]

Am 2008-03-05 13:10:37, schrieb Bob McGowan:
 Mark Clarkson wrote:
 On Wed, 05 Mar 2008 12:16:02 -0800
 Bob McGowan [EMAIL PROTECTED] wrote:
 
 Brian wrote:
 So can you explain exactly what the first  ( echo $teststring )
 does exactly please?

man bash

8--
echo EOD
   Here Documents
   This  type  of  redirection  instructs the shell to read input from the
   current source until a line containing  only  word  (with  no  trailing
   blanks)  is seen.  All of the lines read up to that point are then used
   as the standard input for a command.

   The format of here-documents is:

  [-]word
  here-document
  delimiter

   No parameter expansion, command substitution, arithmetic expansion,  or
   pathname expansion is performed on word.  If any characters in word are
   quoted, the delimiter is the result of quote removal on word,  and  the
   lines  in the here-document are not expanded.  If word is unquoted, all
   lines of the here-document are subjected to parameter  expansion,  com-
   mand  substitution,  and arithmetic expansion.  In the latter case, the
   character sequence \newline is ignored, and \ must be used  to  quote
   the characters \, $, and `.

   If the redirection operator is -, then all leading tab characters are
   stripped from input lines and  the  line  containing  delimiter.   This
   allows  here-documents within shell scripts to be indented in a natural
   fashion.
EOD
8--


Thanks, Greetings and nice Day
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Probably very stupid script/bash question

[Bob McGowan]

Michelle Konzack wrote:

Am 2008-03-05 14:13:33, schrieb Brian:
teststring=one two three four five six 
{ read A B C D E F; }  ( echo $teststring ) 
echo Data received = $E Bytes 

 END OF REPLIED MESSAGE 

This look a little bit weird. Why not use:

8
read A B C D E F EOF
one two three four five six
EOF
8

and

8
teststring=one two three four five six 


read A B C D E F EOF
$teststring
EOF

echo Data received = $E Bytes 
8


no need for a stupid resources eating subschell expecialy on a ARM.

:-)



Actually, the example code is a trivial example used to illustrate how 
to use process substitution.  A real case might have a series of 
commands running, or a single large application, etc., from which you 
want to read the output in some asynchronous way.


In some cases, using a here doc would be an option, but in the cases 
mentioned above, you don't know what the text will be until you fetch 
it.  It's a run time issue.


--
Bob McGowan


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Probably very stupid script/bash question

[Bob McGowan]

Michelle Konzack wrote:

Am 2008-03-05 13:10:37, schrieb Bob McGowan:

Mark Clarkson wrote:

On Wed, 05 Mar 2008 12:16:02 -0800
Bob McGowan [EMAIL PROTECTED] wrote:


Brian wrote:

So can you explain exactly what the first  ( echo $teststring )
does exactly please?


man bash

8--

### deleted 'here' doc usage ###




The syntax ... (command ...) is *not* a here document.  You should 
refer back to the original discussion for details.


A brief synopsis is:  '(command ...)' will substitute the command 
output into a named piped, which is then read.  Using the second '', 
separated by white space, will then redirect input from the named pipe 
to a builtin command, such as read.


If you take the example command and remove the space between the two 
less than symbols, you get a syntax error.


--
Bob McGowan


smime.p7s
Description: S/MIME Cryptographic Signature