Re: /bin/sh should set SHELL to /bin/sh

2017-07-14 Thread Dan Douglas 
On 07/14/2017 03:13 PM, Greg Wooledge wrote:
> On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote:
>> IMO, if SHELL gets unset (it is usually initialised by login, or its
>> equivalent), it should simply stay unset, and not be set to anything,
>> until some user (or script) decides to set it again.
> 
> wooledg:~$ unset SHELL
> wooledg:~$ bash -c 'echo "$SHELL"'
> /bin/bash
> wooledg:~$ ksh -c 'echo "$SHELL"'
> /bin/sh
> wooledg:~$ zsh -c 'echo "$SHELL"'
> 
> wooledg:~$ tcsh -c 'echo "$SHELL"'
> SHELL: Undefined variable.
> 
> Looks like there's not much agreement here.
> 

Good thing is bash doesn't export SHELL if it wasn't already exported,
and most shells seem to preserve the value of SHELL exported by some
parent. I see mksh sets -x if SHELL was previously unset... I suppose
that might cause a problem in some scenario (but probably not).



signature.asc
Description: OpenPGP digital signature

Re: /bin/sh should set SHELL to /bin/sh

2017-07-14 Thread Greg Wooledge 
On Sat, Jul 15, 2017 at 02:59:41AM +0700, Robert Elz wrote:
> IMO, if SHELL gets unset (it is usually initialised by login, or its
> equivalent), it should simply stay unset, and not be set to anything,
> until some user (or script) decides to set it again.

wooledg:~$ unset SHELL
wooledg:~$ bash -c 'echo "$SHELL"'
/bin/bash
wooledg:~$ ksh -c 'echo "$SHELL"'
/bin/sh
wooledg:~$ zsh -c 'echo "$SHELL"'

wooledg:~$ tcsh -c 'echo "$SHELL"'
SHELL: Undefined variable.

Looks like there's not much agreement here.

Re: /bin/sh should set SHELL to /bin/sh

2017-07-14 Thread Robert Elz 
Date:Thu, 13 Jul 2017 23:02:49 -0400
From:Chet Ramey 
Message-ID:  <102d254a-d321-20c0-b8d6-9f2257861...@case.edu>

  | Posix, the closest thing we have to a standard description of SHELL, says:

It does, but POSIX doesn't say the shell is intended to set it.
That is, it defines its purpose, but leaves unstated where it comes from.

IMO, if SHELL gets unset (it is usually initialised by login, or its
equivalent), it should simply stay unset, and not be set to anything,
until some user (or script) decides to set it again.

kre

Re: request

2017-07-14 Thread Greg Wooledge 
On Fri, Jul 14, 2017 at 11:09:25AM +0200, t wrote:
> #
> [me@linuxbox me]$ ./trouble.bash
> ./trouble.bash: line 8430: unexpected EOF while looking for matching "
> ./trouble.bash: line 8440 systax error: unexpected end of file

Your problem is that your script is about 8300 lines longer than it
should be.  Writing a bash script that's over ~100 lines is crazy.

Yours is over 8000 lines.

I have no words.

> echo "We suggest check $VAR"
> echo "because this lines of file, contain an odd number of quotes "

But lines are explicitly *allowed* to contain an odd number of quotes.
This is how multi-line string constants are created.

body="This is the body of an email.  It has
multiple lines.  There are so many words
that they don't all fit on one line."

When the parser encouters a syntax error, it *cannot* know where the real
problem is; only that there *is* one, somewhere.  You as the programmer
have to be the one to track it down and fix it.

You know that the syntax error originates somewhere *on* or *before*
the line number where the parser hit the brick wall and stopped.  That's
all you know.  You don't know whether it's actually a missing quote.
It could be a missing } or a missing fi or a missing esac or a missing
done, or ANY OTHER missing or incorrect syntax element.

That is *one* of the reasons why bash scripts should be kept small.

> 2. Please hide e-mail for google bots, or remove this e-mail after read.

Screw you.  (And yes, this is the sanitized version.)

bug in cd

2017-07-14 Thread Kae Verens 
I'm not even sure if cd is part of Bash?

anyway - if you type any of the following:
cd / ; pwd
cd /// ; pwd
cd  ; pwd

the CLI always reports
/

but, if you do this:
cd // ; pwd

then the CLI reports
//

-- 
Kae Verens
http://kvsites.ie/

request

2017-07-14 Thread t 


1. Missing quotes

#
[me@linuxbox me]$ ./trouble.bash
./trouble.bash: line 8430: unexpected EOF while looking for matching "
./trouble.bash: line 8440 systax error: unexpected end of file
#

We have 2017, please add suggestions for errors

For example for "
#===
VAR=$(cat file | sed 's/[^"]//g' | awk '{ print length }' | cat -n | grep 
"[13579]$" |  awk '{print $1}')

echo "We suggest check $VAR"
echo "because this lines of file, contain an odd number of quotes "
#===

2. Please hide e-mail for google bots, or remove this e-mail after read.
Thanks !:-)