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

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

bash re-direction?

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

Contents

  bash re-direction? Avoid9Pdf@gmail.com - 2013-03-13 13:37 +0000
    Re: bash re-direction? "Chris F.A. Johnson" <cfajohnson@gmail.com> - 2013-03-13 17:12 -0400
    Re: bash re-direction? Chick Tower <c.tower@deadspam.com> - 2013-03-14 21:24 +0000
      A working incantation for openssl to gmail via SSL and TLS J G Miller <miller@yoyo.ORG> - 2013-03-14 22:01 +0000
        Re: A working incantation for openssl to gmail via SSL and TLS J G Miller <miller@yoyo.ORG> - 2013-03-14 22:18 +0000
      Re: bash re-direction? Unknown <dog@gmail.com> - 2013-03-24 10:14 +0000
        Re: bash re-direction? J G Miller <miller@yoyo.ORG> - 2013-03-24 15:47 +0000
          Re: bash re-direction? Unknown <dog@gmail.com> - 2013-03-25 18:19 +0000
            Re: bash re-direction? J G Miller <miller@yoyo.ORG> - 2013-03-25 20:01 +0000
              Re: bash re-direction? Chick Tower <c.tower@deadspam.com> - 2013-03-27 02:21 +0000
                Re: bash re-direction? J G Miller <miller@yoyo.ORG> - 2013-03-27 13:33 +0000
            Re: bash re-direction? The Natural Philosopher <tnp@invalid.invalid> - 2013-03-26 01:31 +0000
      Re: bash re-direction? Unknown <dog@gmail.com> - 2013-03-24 10:20 +0000

#7473 — bash re-direction?

This is not what's normaly refered to by bash re-direction,
but I don't know what to call it.

It's about `echo` & `cat`

It's about "he said, she said, he said", when several processes are
'cascaded'.  It's not obvious who is talking.

BTW if you've also been sweating-blood to get gmail to
smtp NON-http, this finally did it for me:
openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof
 BUT!!
Who's talking to the remote server, after I enter that line in bash?

Is `openssl` outputting to the inetStak and inputting from the keyboard.
BUT!!
When I wrap the dialog in `expect`, the last stage: after `DATA`
doesn't echo any more. But when I keyin/paste, each stage
gives the echo-confirm and the email arrives.

Obviously, I want to wrap my email-body to send with one action.
How would I do that?

I've just remembered that I've got a bash-scrip from <?Jonston?>;
so I'll see if that explains it.

== TIA.

 
 

[toc] | [next] | [standalone]

#7474

On 2013-03-13, Avoid9Pdf@gmail.com wrote:
> This is not what's normaly refered to by bash re-direction,
> but I don't know what to call it.
>
> It's about `echo` & `cat`
>
> It's about "he said, she said, he said", when several processes are
> 'cascaded'.  It's not obvious who is talking.

   That puts one command in the background and runs another command.
   It's the same as

$(echo) &
$(cat)

  Or did you mean:

echo &
cat


-- 
   Chris F.A. Johnson, <http://cfajohnson.com>
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

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

#7477

On 2013-03-13, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
> BTW if you've also been sweating-blood to get gmail to
> smtp NON-http, this finally did it for me:
> openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof
>  BUT!!

Could you please direct the rest of us to where you found this
information?  It sounds useful to me, too.
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

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

#7478 — A working incantation for openssl to gmail via SSL and TLS

On Thursday, March 14th, 2013, at 21:24:37h +0000, Chick Tower asked:

> Could you please direct the rest of us to where you found this
> information?

At a guess, because exactly the same incantation is given, at

  <http://stackoverflow.COM/questions/12367298/ssl-tls-cant-connect-to-gmail-from-php>

QUOTE

   I CAN connect to gmail and send mail throw openssl like this:

   TLS:   openssl s_client -starttls smtp -connect smtp.gmail.com:587 -crlf -ign_eof

   SSL:   openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof

   so, the ports all open

UNQUOTE

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

#7479 — Re: A working incantation for openssl to gmail via SSL and TLS

> On Thursday, March 14th, 2013, at 21:24:37h +0000, Chick Tower asked:
> 
> Could you please direct the rest of us to where you found this
> information?

There is also

   <https://www.carbonwind.NET/blog/post/Using-openssl-s_client-or-gnutls_cli-to-connect-to-a-STARTTLS-or-SSL-wrapped-service-SMTP-IMAP-POP3-server-and-to-an-explicit-or-implicit-FTP-server.aspx>

which has considerable details on various secure connection methods
with TLS and SSL.

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

#7613

On Thu, 14 Mar 2013 21:24:37 +0000, Chick Tower wrote:

> On 2013-03-13, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
>> BTW if you've also been sweating-blood to get gmail to smtp NON-http,
>> this finally did it for me: openssl s_client -connect
>> smtp.gmail.com:465 -crlf -ign_eof
>>  BUT!!
> 
OK, I'm back on this dog-task!

> Could you please direct the rest of us to where you found this
> information?  It sounds useful to me, too.

When I started learning to read, I learned to spell c.a.t, but I didn't
make a record of the 'authority'.

Summary of progress to date, to smtp to gmail:---
Summary of progress to: ssl-connect to smtp.gmail.com:465

I have the following text visible, to copy the lines,
to paste to a shell/VT, and the indented numbers are what the gmail server
  should have in its reply -- for when I later extend this to a full 
script.
BTW, I previously used expect, with these confirming-numbers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof
    250

EHLO gmail.com
   250

AUTH LOGIN
 334

<MyName@gmail.com decoded to base64>
  334

<My-gmail password decoded to base64>
  235

MAIL FROM: <ME@gmail.com>
  250

RCPT TO:<CONFIRMadr.eas@gmail.com>
  250

DATA
  354

Subject: opensslc2LB 23 Mar
Date: 24 Mar 2013
Line after space-line separator
line-2
line-3
line-4
end with <CRLF>.<CRLF>
.

  250

quit
  221
~~~~~~~~~~~~~~~~ end of my 'copy template'~~~~~~~~~~~~

NB. the 'closing "." line must have no trailing spaces, so I do it by 
hand,
 instead of pasting.
========================================
My old accumulated notes contain:--
Newsgroups: comp.os.linux.misc
Subject: Re: need bash mail syntax help
From: Pascal Bourguignon <spam@thalassa.informatimago.com>

Grant Edwards <grante@visi.com> writes:

> In article <c1u7pr$1merb6$1@ID-178899.news.uni-berlin.de>, Anthony 
Ewell wrote:
> 
...
Why rely on external programs?  You only need a kernel and bash!

./smtp.sh sender@example.com recip-1@example.com recip-2@example.com <<EOF
#!/bin/bash
...
#AUTHORS
#    <PJB> Pascal Bourguignon <pjb@informatimago.com>
...
smtp_server=localhost
local_name=localhost
if [ "$1" = "--log" ] ; then shift ; trace=echo ; else trace=true ; fi
from="$1" ; shift # the rest of arguments are envelop recipients
log=/dev/tty
message=/tmp/message.$$
trap "rm $message" 0
cat>$message
(
    read line 0<&3 ; $trace "$line">$log
    case "$line" in 2*) ;; *) echo "QUIT" 1>&3 ; exit 0 ;; esac
    echo "HELO $local_name" 1>&3
    read line 0<&3 ; $trace "$line">$log
    case "$line" in 2*) ;; *) echo "QUIT" 1>&3 ; exit 0 ;; esac
    echo "MAIL FROM: <${from}>" 1>&3
...
        echo "." 1>&3
        read line 0<&3 ; $trace "$line">$log
        case "$line" in 
        2*) [ "$trace" != ":" ] && echo "Message sent">$log ;;
        *) echo "Could not send the emssage.">$log ;; 
        esac
    fi
    echo "QUIT" 1>&3
) 3<>/dev/tcp/$smtp_server/25   #  <---- transport to server !!
exit 0
~~~~~~~~~ end of extract ~~~~~~~~~~~~~~

The syntax which I don't understand and seems KEY to this & what
I'm trying to achieve is:--

cat>$message
(
...
) 3<>/dev/tcp/$smtp_server/25  

It's the complex interaction of various processes running 
that kills me.

Apparently `openssl` is set to run in the background.
And the standard-input is able to 'butt-in' too.
Automating it by a script, adds a further level of complication.

What I want to do is take the existing PROVEN, and wrap it
in a script. But UNDERSTAND how it works too.

== Chris Glur.

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

#7624

On Sunday, March 24th, 2013, at 10:14:26h +0000,
Chris Glur confessed:

> When I started learning to read, I learned to spell c.a.t,
> but I didn't make a record of the 'authority'.

So you admit that your memory is now so bad that you
cannot remember who were your primary school teachers?

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

#7656

On Sun, 24 Mar 2013 15:47:44 +0000, J G Miller wrote:

> On Sunday, March 24th, 2013, at 10:14:26h +0000, Chris Glur confessed:
> 
>> When I started learning to read, I learned to spell c.a.t, but I didn't
>> make a record of the 'authority'.
> 
> So you admit that your memory is now so bad that you cannot remember who
> were your primary school teachers?

I can't remember what I had for breakfast; but I fetched, tested and 
filed your pointers to [gnui*? the new one]. The reason why I appear 
stubborn on this [also] matter, is that I didn't WANT to know about ssl, 
but once I've opened the can-o-worms and an important question has been 
raised, I won't just sweep it under the carpet, eg. by buying some snake-
oil, because the problem [& note, I don't euphemise it to a 'challenge'] 
will come back.
Coming from an embedded background, I lack a valid mental-model of the 
multiple processes talking-to-each-other, and eg. how the shell spawns
eg. `expect` which sends/receives to/from an tcp-stack ......and........

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

#7657

On Monday, March 25th, 2013, at 18:19:51h +0000, Chris Glur confessed:

> I can't remember what I had for breakfast;

Obviously it was not very memorable then.   ;)

> but I fetched, tested and filed your pointers to [gnui*? the new one].

And hopefully that resolved the problem of the missing Perl module.

> The reason why I appear stubborn on this [also] matter, is that
> I didn't WANT to know about ssl

If one does not want to use something, then one can stubbornly refuse
to learn anything about it, but if one does want to use something,
then at the very minimum, a basic understanding is a pre-requisite.

> but once I've opened the can-o-worms

Only you can decided whether or not to open the can of worms, but
if you never open it, you will never know whether or not the
worms are alive or dead.

> eg. by buying some snake-oil

Have you checked to see if there are any snake oil certificates 
on your machine?

locate snakeoil

/etc/ssl/certs/ssl-cert-snakeoil.pem
/etc/ssl/private/ssl-cert-snakeoil.key

Snake oil can be used as a temporary fix.

And if the worst comes to the worst, one could always call in
the Ding Dong Plumbers on Langdale Street in Dinwiddie, Germiston.

> Coming from an embedded background, I lack a valid mental-model of the 
> multiple processes talking-to-each-other, and eg. how the shell spawns
> eg. `expect` which sends/receives to/from an tcp-stack ......and........

Well consider that nowadays that Android (a derivative of Linux)
and GNU/Linux its-self now run on all sorts of embedded systems.

Expect is a Tcl extension designed for scripting applications as
a tool for automating access to interactive applications. Expect
its-self does NOT directy send/receive to/from a tcp-stack.

I hope that clears up any lingering confusion.

With regard to shell re-direction, perhaps a quick reminder of
the basics would help.

In Unix and GNU/Linux systems there are there standard input/output descriptors

0 is standard input
1 is standard output
2 is standard error

The Bourne and bash shells allow you to independently redirect
standard input, standard output, and standard error to different
normal files or special files such as pipes, or sockets.

With regard to the & character, that is a special character which
means put the process in the background.

But if two && are used together, such as in

       executable_1 {parameters} && executable 2 {parameters}

that means only run executable 2 if executable 1 terminated
with an exit status of 0.

If one does not care whether or not executable_1 ran successfully,
then one would use a ; as in      rm -f some_file ; touch some_file

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

#7666

On 2013-03-25, J G Miller <miller@yoyo.ORG> wrote:
> Only you can decided whether or not to open the can of worms, but
> if you never open it, you will never know whether or not the
> worms are alive or dead.

Hey, why bring quantum physics into this discussion????
-- 
                                 Chick Tower

For e-mail:  colm DOT sent DOT towerboy AT xoxy DOT net

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

#7669

On Wednesday, March 27th, 2013, at 02:21:58h +0000, Chick Tower asked:

> Hey, why bring quantum physics into this discussion????

Well at least somebody else was paying attention  ;)

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

#7660

On 25/03/13 18:19, Unknown wrote:
> On Sun, 24 Mar 2013 15:47:44 +0000, J G Miller wrote:
>
>> On Sunday, March 24th, 2013, at 10:14:26h +0000, Chris Glur confessed:
>>
>>> When I started learning to read, I learned to spell c.a.t, but I didn't
>>> make a record of the 'authority'.
>>
>> So you admit that your memory is now so bad that you cannot remember who
>> were your primary school teachers?
>
> I can't remember what I had for breakfast; but I fetched, tested and
> filed your pointers to [gnui*? the new one]. The reason why I appear
> stubborn on this [also] matter, is that I didn't WANT to know about ssl,
> but once I've opened the can-o-worms and an important question has been
> raised, I won't just sweep it under the carpet, eg. by buying some snake-
> oil, because the problem [& note, I don't euphemise it to a 'challenge']
> will come back.
> Coming from an embedded background, I lack a valid mental-model of the
> multiple processes talking-to-each-other, and eg. how the shell spawns
> eg. `expect` which sends/receives to/from an tcp-stack ......and........
>
>
well if you are an embedded man, just think of spawning a sub process as 
a rather unwieldy way to call a subroutine, with arguments, and et  a 
return value, or set of values.

If you haven't a basic grasps of multi-tasking, that too is simple in 
principle.

Imagine a hardware interrupt that comes along, saves your stack pointer 
and your register set,  and does its thing and then tidies up and 
replaces the correct values in all the registers  finishing with an 
IRET. The interrupted program carries on.

A multitasking scheduler is just that. And array of tasks that are not 
running exist as - say - register sets copied into specific memory 
places. when a timer interrupt comes along, the interrupt service 
routine looks at all these processes and if it finds a flag has been set 
by some other program that the one suspended, it stores the current 
register set, and the current return value pushed into the stack, and 
loads all the registers from another task, and then pushes THAT tasks 
return value into the stack. Then an Iret will pop the instruction 
pointer back to where THAt task was when the timer interrupted it.


|As long as different tasks don't attempt to share the same memory, they 
can all happily coexist in splendid isolation from each other, and get 
accorded timeslices on the basis of whether they actually have anything 
to do.

that 'whether they have anything to do' is normally assigned by the 
kernel - e.g. when you call for input, you will get suspended until 
input arrives.

You CAN write programs as threads and use one to wake another up, but 
when you want tow actual user space programs to talk, the easiest thing 
to do is to have a daemon. That's a process that is 'attached' to a 
particular input stream, like a tcp/IP or a unix socket, and itself gets 
'woken up' by input to that stream or a request to pull data off it.

Conventionally when it does get woken up, it spawns a copy of itself 
that is attached to that particular conversation, and becomes a separate 
process.

that daemon can then act as a waker-upper of processes that have opened 
a line of communication with it, as well. So if you run ps -eadf or 
similar on  working computer you will see dozens of processes, most of 
them daemons, doing nothing (0%CPU) and waiting for instructions as to 
what to do next.


Those instructions might happen on a timer expiry, or on user input, or 
in asynchronous interrupts from hardware. so if eg an ethernet paclet 
arrives, the kernel ISR accepts it, and passes it to a low level kernel 
daemon who will look at source and destination ports and wake up the 
daemon its assigned to. That daemon will then deal with it and possibly 
respond, then go back to sleep. That daemon might be a web server  and 
dealing with it may involve  spawning an entire copy of the apache 
server, and sending a load of data back. Or it might be something as 
simple as an echo daemon that just says 'I am here' and sends a simple 
packet back.


Mostly you dont need to know this to use it, but sometimes it helps.

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

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

#7614

On Thu, 14 Mar 2013 21:24:37 +0000, Chick Tower wrote:

> On 2013-03-13, Avoid9Pdf@gmail.com <Avoid9Pdf@gmail.com> wrote:
>> BTW if you've also been sweating-blood to get gmail to smtp NON-http,
>> this finally did it for me: openssl s_client -connect
>> smtp.gmail.com:465 -crlf -ign_eof
>>  BUT!!
> 
OK, I'm back on this dog-task!

> Could you please direct the rest of us to where you found this
> information?  It sounds useful to me, too.

When I started learning to read, I learned to spell c.a.t, but I didn't
make a record of the 'authority'.

Summary of progress to date, to smtp to gmail:---
Summary of progress to: ssl-connect to smtp.gmail.com:465

I have the following text visible, to copy the lines,
to paste to a shell/VT, and the indented numbers are what the gmail server
  should have in its reply -- for when I later extend this to a full 
script.
BTW, I previously used expect, with these confirming-numbers.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
openssl s_client -connect smtp.gmail.com:465 -crlf -ign_eof
    250

EHLO gmail.com
   250

AUTH LOGIN
 334

<MyName@gmail.com decoded to base64>
  334

<My-gmail password decoded to base64>
  235

MAIL FROM: <ME@gmail.com>
  250

RCPT TO:<CONFIRMadr.eas@gmail.com>
  250

DATA
  354

Subject: opensslc2LB 23 Mar
Date: 24 Mar 2013
Line after space-line separator
line-2
line-3
line-4
end with <CRLF>.<CRLF>
.

  250

quit
  221
~~~~~~~~~~~~~~~~ end of my 'copy template'~~~~~~~~~~~~

NB. the 'closing "." line must have no trailing spaces, so I do it by 
hand,
 instead of pasting.
========================================
My old accumulated notes contain:--
Newsgroups: comp.os.linux.misc
Subject: Re: need bash mail syntax help
From: Pascal Bourguignon <spam@thalassa.informatimago.com>

Grant Edwards <grante@visi.com> writes:

> In article <c1u7pr$1merb6$1@ID-178899.news.uni-berlin.de>, Anthony 
Ewell wrote:
> 
...
Why rely on external programs?  You only need a kernel and bash!

./smtp.sh sender@example.com recip-1@example.com recip-2@example.com <<EOF
#!/bin/bash
...
#AUTHORS
#    <PJB> Pascal Bourguignon <pjb@informatimago.com>
...
smtp_server=localhost
local_name=localhost
if [ "$1" = "--log" ] ; then shift ; trace=echo ; else trace=true ; fi
from="$1" ; shift # the rest of arguments are envelop recipients
log=/dev/tty
message=/tmp/message.$$
trap "rm $message" 0
cat>$message
(
    read line 0<&3 ; $trace "$line">$log
    case "$line" in 2*) ;; *) echo "QUIT" 1>&3 ; exit 0 ;; esac
    echo "HELO $local_name" 1>&3
    read line 0<&3 ; $trace "$line">$log
    case "$line" in 2*) ;; *) echo "QUIT" 1>&3 ; exit 0 ;; esac
    echo "MAIL FROM: <${from}>" 1>&3
...
        echo "." 1>&3
        read line 0<&3 ; $trace "$line">$log
        case "$line" in 
        2*) [ "$trace" != ":" ] && echo "Message sent">$log ;;
        *) echo "Could not send the emssage.">$log ;; 
        esac
    fi
    echo "QUIT" 1>&3
) 3<>/dev/tcp/$smtp_server/25   #  <---- transport to server !!
exit 0
~~~~~~~~~ end of extract ~~~~~~~~~~~~~~

The syntax which I don't understand and seems KEY to this & what
I'm trying to achieve is:--

cat>$message
(
...
) 3<>/dev/tcp/$smtp_server/25  

It's the complex interaction of various processes running 
that kills me.

Apparently `openssl` is set to run in the background.
And the standard-input is able to 'butt-in' too.
Automating it by a script, adds a further level of complication.

What I want to do is take the existing PROVEN, and wrap it
in a script. But UNDERSTAND how it works too.

== Chris Glur.

[toc] | [prev] | [standalone]

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

csiph-web