Tuesday 30 May 2006 07:51 skrev Iain Buchanan:
Ah, I was looking in /etc/init.d wondering why I couldn't find it :) I
have bad RAM in my head. I guess sh scripts can be run by sh and bash,
and probably other --sh variants. Not that that helps with this topic,
I was just thinking aloud :)
$
On Tue, 30 May 2006 06:35:39 +0200, Bo Ørsted Andresen wrote:
That of course should have been negated...
if [ -n $PS1 ]
Or even
if [ -n $PS1 ]
or you'll get an error if PS1 is undefined.
--
Neil Bothwick
If the pen is mightier than the sword, and a picture is worth a thousand
words,
Tuesday 30 May 2006 16:19 skrev Neil Bothwick:
Or even
if [ -n $PS1 ]
or you'll get an error if PS1 is undefined.
That explains a LOT! ;) Didn't quite understand why the statement was true
even when the variable was not set...
--
Bo Andresen
pgpDLPBh4Hu7J.pgp
Description: PGP signature
On 5/29/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
Tuesday 30 May 2006 06:48 skrev Iain Buchanan: I see this [ x != x$BLAH ] test all over the place, especially in the /etc/init.d scripts.Maybe -z is not standardised or something?
Dunno why people use it.Having searched a little further I
Sunday 28 May 2006 18:21 skrev Kevin O'Gorman:
if [ x != x$PS1 ] ; then
SHELL_LOGIN=1
else
# Probably scp; empty string is false
SHELL_LOGIN=
fi
if [ -n $SHELL_LOGIN ]
[...]
IMHO it seems kind of lame to use one shell variable to create another instead
of just using the one
Tuesday 30 May 2006 06:26 skrev Bo Ørsted Andresen:
if [ -z $PS1 ]
That of course should have been negated...
if [ -n $PS1 ]
--
Bo Andresen
pgpnSDqa93h5t.pgp
Description: PGP signature
On Tue, 2006-05-30 at 06:26 +0200, Bo Ørsted Andresen wrote:
Also shouldn't:
if [ x != x$PS1 ]
be equivalent to:
if [ -z $PS1 ]
I see this [ x != x$BLAH ] test all over the place, especially in
the /etc/init.d scripts. Maybe -z is not standardised or something?
Dunno why people use
Tuesday 30 May 2006 06:48 skrev Iain Buchanan:
I see this [ x != x$BLAH ] test all over the place, especially in
the /etc/init.d scripts. Maybe -z is not standardised or something?
Dunno why people use it.
You do?? I don't:
$ grep \[a-z]\ /etc/init.d/*
/etc/init.d/halt.sh:if [[
Tuesday 30 May 2006 06:48 skrev Iain Buchanan:
I see this [ x != x$BLAH ] test all over the place, especially in
the /etc/init.d scripts. Maybe -z is not standardised or something?
Dunno why people use it.
Having searched a little further I have been able to locate a few scripts that
uses
On Tue, 2006-05-30 at 07:10 +0200, Bo Ørsted Andresen wrote:
Tuesday 30 May 2006 06:48 skrev Iain Buchanan:
I see this [ x != x$BLAH ] test all over the place, especially in
the /etc/init.d scripts. Maybe -z is not standardised or something?
Dunno why people use it.
Having searched a
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote:
That does not work for ssh/scp sessions.I usually test $PS1 to tell if it's really a shell -- the variable does not even exist for an scp session, although .bashrc gets called.can you give us an example of what your .bashrc looks like?
Well, the
On May 28, 2006, at 11:21 AM, Kevin O'Gorman wrote:
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote:
That does not work for ssh/scp sessions. I usually test $PS1 to tell
if it's really a shell -- the variable does not even exist for an
scp session,
although .bashrc gets called.
can you give
On 5/28/06, John Jolet [EMAIL PROTECTED] wrote:
On May 28, 2006, at 11:21 AM, Kevin O'Gorman wrote: On 5/27/06, John Jolet [EMAIL PROTECTED] wrote: That does not work for ssh/scp sessions.I usually test $PS1 to tell
if it's really a shell -- the variable does not even exist for an scp session,
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote:
Password: debug1: packet_send2: adding 32 (len 25 padlen 7 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64)
debug1: ssh-userauth2 successful:
Okay, I set LogLevel=DEBUG3 and reloaded sshd, but I got no more
output than usual:
May 27 09:14:55 treat sshd[11739]: Received SIGHUP; restarting.
May 27 09:14:55 treat sshd[2352]: Server listening on 0.0.0.0 port 22.
May 27 09:15:31 treat sshd[2356]: Connection from 64.166.164.53
port 32776
On 5/27/6, John Jolet [EMAIL PROTECTED] wrote:
Okay, I set LogLevel=DEBUG3 and reloaded sshd, but I got no more output than usual: May 27 09:14:55 treat sshd[11739]: Received SIGHUP; restarting. May 27 09:14:55 treat sshd[2352]: Server listening on
0.0.0.0 port 22. May 27 09:15:31 treat
That was the hint I needed. It's /bin/bash, which reminded me I
just changed something
in .bashrc which outputs a message and does some other stuff which
must be
confusing scp. In fact, I just confirmed that by commenting it
out. Now scp works too.
So: PROBLEM SOLVED.
Now I just have
On 5/27/06, John Jolet [EMAIL PROTECTED] wrote:
That was the hint I needed.It's /bin/bash, which reminded me I just changed something in .bashrc which outputs a message and does some other stuff which must be confusing scp.In fact, I just confirmed that by commenting it
out.Now scp works too.
That does not work for ssh/scp sessions. I usually test $PS1 to tell
if it's really a shell -- the variable does not even exist for an
scp session,
although .bashrc gets called.
can you give us an example of what your .bashrc looks like?
--
gentoo-user@gentoo.org mailing list
On 5/25/06, John Jolet [EMAIL PROTECTED] wrote:
On May 25, 2006, at 1:07 PM, Kevin O'Gorman wrote: Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just downright broken.I have been running ssh daemon(s) for so long I
don't even remember how I set them up.They Just Ran
On 5/26/06, Kevin O'Gorman [EMAIL PROTECTED] wrote:
On 5/25/06, John Jolet [EMAIL PROTECTED]
wrote:
On May 25, 2006, at 1:07 PM, Kevin O'Gorman wrote: Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just downright broken.I have been running ssh daemon(s) for so long I
Somewhere along the line, ssh and ssh2 have gotten conflated, confused or just
downright broken. I have been running ssh daemon(s) for so long I don't even
remember how I set them up. They Just Ran (TM).
For a short while, ssh connections to here (home) from work have taken an
unusually long time
On May 25, 2006, at 1:07 PM, Kevin O'Gorman wrote:
Somewhere along the line, ssh and ssh2 have gotten conflated,
confused or just
downright broken. I have been running ssh daemon(s) for so long I
don't even
remember how I set them up. They Just Ran (TM).
For a short while, ssh
23 matches
Mail list logo
