sh[it] and What am I missing here?

[Baho Utot]

I have tried this on 11-CURRENT and 10.1 release...........

Just doing some scripting ( thought I was using a bourne shell but may
scripting was puking) so I came across this........

***@baho-utot:~ # set
_
addsuffix
anyerror
argv ()
autoexpand
autolist ambiguous
autorehash
csubstnonl
cwd /root
dirstack /root
echo_style bsd
edit
euid 0
euser root
filec
gid 0
group wheel
history 1000
home /root
killring 30
loginsh
mail /var/mail/root
owd
path (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin
/usr/local/bin /root/bin)
prompt %N@%m:%~ %#
prompt2 %R?
prompt3 CORRECT>%R (y|n|e|a)?
promptchars %#
savehist (1000 merge)
shell /bin/csh
shlvl 1
status 0
tcsh 6.18.01
term xterm
tty pts/0
uid 0
user root
version tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-amd-FreeBSD) options
wide,nls,dl,al,kan,sm,rh,color,filec

OK tcsh as I thought


OK switch shells

***@baho-utot:~ # /bin/sh
# set
BLOCKSIZE=K
EDITOR=vi
GROUP=wheel
HOME=/root
HOST=baho-utot.bildanet.com
HOSTTYPE=FreeBSD
IFS='
'
LOGNAME=root
MACHTYPE=x86_64
MAIL=/var/mail/root
OPTIND=1
OSTYPE=FreeBSD
PAGER=more
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
PPID=1373
PS1='# '
PS2='> '
PS4='+ '
PWD=/root
SHELL=/bin/csh
SHLVL=1
TERM=xterm
USER=root
VENDOR=amd
#

Why is the SHELL variable still set to /bin/csh

After the /bin/sh am I into a bourne shell or what?

[Manas Bhatnagar]

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

[Baho Utot]

Post by Manas Bhatnagar

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

env: bash: No such file or directory

[jd1008]

Post by Baho Utot

Post by Manas Bhatnagar

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

env: bash: No such file or directory

Sorry, for barging in at this point.
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

where <username> should all be replaced by your login name.

This will give you a vi screen where you change your login shell
to whatever you want it to be.

After that , you need to make sure that the rc and profile files that
are executed
by your chosen shell, export the variable
SHELL=<your shell that you chose in the previous command above>

for example:

export SHELL=/bin/bash

HTH.

[jd1008]

Post by Baho Utot

Post by Manas Bhatnagar

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

env: bash: No such file or directory

Sorry, for barging in at this point.
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

where <username> should all be replaced by your login name.

This will give you a vi screen where you change your login shell
to whatever you want it to be.

After that , you need to make sure that the rc and profile files that
are executed
by your chosen shell, export the variable
SHELL=<your shell that you chose in the previous command above>

for example:

export SHELL=/bin/bash

HTH.

[Baho Utot]

Post by jd1008

Post by Baho Utot

Post by Manas Bhatnagar

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

env: bash: No such file or directory

Sorry, for barging in at this point.
Do I understand correctly that you want bash to be your shell?

No I don't want to have sh as my shell or change the default shell.
I am just writing a script to build packages from ports on a new install.
As bash is not available but sh was I'll use that to script into.

Now when I was writing the script syntax that should have been a Ok in
sh it was/is failing.
After some head scratching I found that maybe I wasn't really using or
in a bourne shell ie /bin/sh.
That made me think that even though I have #!/bin/sh at the top of the
script some how I wasn't really getting sh but csh.

So here is what I tried.
Power on console ( boot computer )
Login in as root
/bin/sh

set # to show environment etc
WTF SHELL says I am in csh????

It should say SHELL=/bin/sh

Hence my question here as to what is going on.

[David Christensen]

On 06/05/2016 08:38 AM, Baho Utot wrote:
...
...

Post by Baho Utot
shell /bin/csh

...

Post by Baho Utot
tcsh 6.18.01

...

Post by Baho Utot
OK tcsh as I thought

...

Post by Baho Utot
OK switch shells
# set

...

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...

Because you are invoking a program (/bin/sh) and that program did not
modify the SHELL environment variable.

Post by Baho Utot
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

+1

Take a look at:

https://www.freebsd.org/doc/en/articles/linux-users/shells.html


David

[David Christensen]

Post by Baho Utot
No I don't want to have sh as my shell or change the default shell.
I am just writing a script to build packages from ports on a new install.
As bash is not available but sh was I'll use that to script into.
Now when I was writing the script syntax that should have been a Ok in
sh it was/is failing.
After some head scratching I found that maybe I wasn't really using or
in a bourne shell ie /bin/sh.
That made me think that even though I have #!/bin/sh at the top of the
script some how I wasn't really getting sh but csh.
So here is what I tried.
Power on console ( boot computer )
Login in as root
/bin/sh
set # to show environment etc
WTF SHELL says I am in csh????
It should say SHELL=/bin/sh
Hence my question here as to what is going on.

Is your script executable?

# chmod +x scriptname


Does it have a shebang line?

#!/bin/sh


Does it make use of the SHELL variable?


David

[Baho Utot]

Post by David Christensen

Post by Baho Utot
No I don't want to have sh as my shell or change the default shell.
I am just writing a script to build packages from ports on a new
install.
As bash is not available but sh was I'll use that to script into.
Now when I was writing the script syntax that should have been a Ok in
sh it was/is failing.
After some head scratching I found that maybe I wasn't really using or
in a bourne shell ie /bin/sh.
That made me think that even though I have #!/bin/sh at the top of the
script some how I wasn't really getting sh but csh.
So here is what I tried.
Power on console ( boot computer )
Login in as root
/bin/sh
set # to show environment etc
WTF SHELL says I am in csh????
It should say SHELL=/bin/sh
Hence my question here as to what is going on.

Is your script executable?
# chmod +x scriptname

Yes

Post by David Christensen
Does it have a shebang line?
#!/bin/sh

Yes

Post by David Christensen
Does it make use of the SHELL variable?

No

It also behaves as if it is in tcsh/csh from the command prompt.... Ok
you can try this from home ; )

login in as a user ( non root )
set
SHELL is set to SHELL=/bin/sh
Ok now try
su - (give password)
set
SHELL=/bin/csh Ok that makes sense
Now
/bin/sh
set
SHELL=/bin/csh WTF?

Log out of all the

login as root
set
SHELL=/bin/csh Ok that makes sense
/bin/sh
set
SHELL=/bin/csh WTF?

It looks to me ( if I am not missing something here )
That I can only get to sh by loging in as a user...Again WTF

[Steve O'Hara-Smith]

On Sun, 5 Jun 2016 09:31:53 -0700

Post by David Christensen

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...
Because you are invoking a program (/bin/sh) and that program did not
modify the SHELL environment variable.

This is the correct explanation, nothing automatically changes
$SHELL when you execute a program - even if that program is a shell, the
variable isn't intended to tell you what you're running just what your
default shell is.

[Baho Utot]

Post by David Christensen
...
...

Post by Baho Utot
shell /bin/csh

...

Post by Baho Utot
tcsh 6.18.01

...

Post by Baho Utot
OK tcsh as I thought

...

Post by Baho Utot
OK switch shells
# set

...

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...
Because you are invoking a program (/bin/sh) and that program did not
modify the SHELL environment variable.

Post by Baho Utot
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

+1
https://www.freebsd.org/doc/en/articles/linux-users/shells.html
David

I understood that, But I do not want to change the default shell.
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script to
build some ports. That's were the trouble lies. ie functions not
returning status for example:

test.sh
chmod +x test.sh

#!/bin/sh

func() {
echo "Yep it's me"
return 1
}

if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi

./test.sh

[: func: unexpected operator

[Ernie Luzar]

Post by Baho Utot

Post by David Christensen
...
...

Post by Baho Utot
shell /bin/csh

...

Post by Baho Utot
tcsh 6.18.01

...

Post by Baho Utot
OK tcsh as I thought

...

Post by Baho Utot
OK switch shells
# set

...

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...
Because you are invoking a program (/bin/sh) and that program did not
modify the SHELL environment variable.

Post by Baho Utot
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

+1
https://www.freebsd.org/doc/en/articles/linux-users/shells.html
David

I understood that, But I do not want to change the default shell.
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script to
build some ports. That's were the trouble lies. ie functions not
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator

I think your problem is where you are placing your script.
You have to place your script in a path that is auto searched for
executable scripts.

Place your script in /usr/local/bin on your development pc and on the
new installed os pc. Then just entering the script on the console
command line will cause it to execute. BY the way your script doesn't
need to be suffixed with .sh to work.

[Baho Utot]

Post by Ernie Luzar

Post by Baho Utot

Post by David Christensen
...
...

Post by Baho Utot
shell /bin/csh

...

Post by Baho Utot
tcsh 6.18.01

...

Post by Baho Utot
OK tcsh as I thought

...

Post by Baho Utot
OK switch shells
# set

...

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...
Because you are invoking a program (/bin/sh) and that program did
not modify the SHELL environment variable.

Post by Baho Utot
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

+1
https://www.freebsd.org/doc/en/articles/linux-users/shells.html
David

I understood that, But I do not want to change the default shell.
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script
to build some ports. That's were the trouble lies. ie functions not
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator

I think your problem is where you are placing your script.
You have to place your script in a path that is auto searched for
executable scripts.

./<filespec.sh> fixes that

Post by Ernie Luzar
Place your script in /usr/local/bin on your development pc and on the
new installed os pc. Then just entering the script on the console
command line will cause it to execute. BY the way your script doesn't
need to be suffixed with .sh to work.

It does need the suffix .sh because if it is missing I fail to
function...... the computer does just fine.

[Baho Utot]

Post by Baho Utot
So here is what I tried.
Power on console ( boot computer )
Login in as root
/bin/sh
set # to show environment etc
WTF SHELL says I am in csh????
It should say SHELL=/bin/sh
Hence my question here as to what is going on.

It seems the $SHELL variable is derived from the settings for the
account you log into. That variable persists when you run another shell,
as (a) the base environment is inherited by child processes; and (b) the
(interactive) shell is just another running user program at that point,
not a base working environment itself.
Log in as root and start a different (interactive) shell, and the
variable will remain unchanged. Log in as a normal user and start
another shell, and you'll get the same result. Log in as any user and
`su` to any other user---simulating a new login---and the value of the
variable will change to the user shell for the new account.
As I understand it, you can have a script you've executed change the
variable having it simulate a login shell and parse a custom
configuration file. See the "Invocation" section of the sh(8) man page
for an explanation.

Ok, But I think I will need to talk to Jack Daniels first then I will
have a look at the man page

[Brandon J. Wandersee]

Post by Baho Utot
So here is what I tried.
Power on console ( boot computer )
Login in as root
/bin/sh
set # to show environment etc
WTF SHELL says I am in csh????
It should say SHELL=/bin/sh
Hence my question here as to what is going on.

It seems the $SHELL variable is derived from the settings for the
account you log into. That variable persists when you run another shell,
as (a) the base environment is inherited by child processes; and (b) the
(interactive) shell is just another running user program at that point,
not a base working environment itself.

Log in as root and start a different (interactive) shell, and the
variable will remain unchanged. Log in as a normal user and start
another shell, and you'll get the same result. Log in as any user and
`su` to any other user---simulating a new login---and the value of the
variable will change to the user shell for the new account.

As I understand it, you can have a script you've executed change the
variable having it simulate a login shell and parse a custom
configuration file. See the "Invocation" section of the sh(8) man page
for an explanation.

[jd1008]

Post by Ernie Luzar

Post by Baho Utot

Post by David Christensen
...
...

Post by Baho Utot
shell /bin/csh

...

Post by Baho Utot
tcsh 6.18.01

...

Post by Baho Utot
OK tcsh as I thought

...

Post by Baho Utot
OK switch shells
# set

...

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...
Because you are invoking a program (/bin/sh) and that program did
not modify the SHELL environment variable.

Post by Baho Utot
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

+1
https://www.freebsd.org/doc/en/articles/linux-users/shells.html
David

I understood that, But I do not want to change the default shell.
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script
to build some ports. That's were the trouble lies. ie functions not
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator

I think your problem is where you are placing your script.
You have to place your script in a path that is auto searched for
executable scripts.
Place your script in /usr/local/bin on your development pc and on the
new installed os pc. Then just entering the script on the console
command line will cause it to execute. BY the way your script doesn't
need to be suffixed with .sh to work.

Hey Baho,
Well, your login rc files (such as .cshrc or whatever other rc or
profies files are executed,
they set your default shell to (as you indicated) /bin/csh.
Since you do not want to change that, then I suggest that your shell
script you are working
with have this code just after the shebang line:

export SHELL=/bin/sh

then code you functions and script after that.

The shell variable value will only affect the shell you are executing
and any other
shell scripts you run from there (as long as those shell scripts are
shebanged with
#!/bin/sh
and do not reset the SHELL variable value.

HTH

[Manas Bhatnagar]

bash isn't installed by default on FreeBSD


  Original Message  
From:baho-***@columbus.rr.com
Sent:June 5, 2016 12:02
To:freebsd-***@freebsd.org
Subject:Re: sh[it] and What am I missing here?

Post by Manas Bhatnagar

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

env: bash: No such file or directory
_______________________________________________
freebsd-***@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-***@freebsd.org"

[Polytropon]

I'm not sure if it has been mentioned in an explicit way, so

Post by Baho Utot
login in as a user ( non root )
set
SHELL is set to SHELL=/bin/sh
Ok now try
su - (give password)
set
SHELL=/bin/csh Ok that makes sense
Now
/bin/sh
set
SHELL=/bin/csh WTF?

This is to be expected. The variable $SHELL corresponds to the
"shell" field of /etc/passwd, which sets the login shell. When
you use "su -", you perform a login operation, so root gets
assigned the login shell as specified by /etc/passwd.

Additionally, "su -" sets the environmental variables for the
root user and therefore overwrites possibly different settings
of the initial user; "su -m" preserves that user's environment.

Post by Baho Utot
login as root
set
SHELL=/bin/csh Ok that makes sense
/bin/sh
set
SHELL=/bin/csh WTF?

Again, the same thing happens. If you execute /bin/sh, it will
inherit the environment previously set up by /bin/csh, which
also contains the $SHELL variable.

Remember, $SHELL does not state which shell you are currently
using - instead, it contains the name of the login shell.

Post by Baho Utot
It looks to me ( if I am not missing something here )
That I can only get to sh by loging in as a user...Again WTF

If you want to interactively run sh (the Bourne shell equivalent
of FreeBSD, which is not a good dialog shell, but the system's
default scripting shell, as well as the dialog shell for the
limited maintenance mode / single user mode), just execute it.

% sh
# _

For scripting use, /bin/sh is recommended over bash except you
really _really_ want to use bash-isms that sh does not implement.
In this case, make sure your script starts with "#!/usr/local/bin/bash"
(the default path after installation of bash from ports) or the
more convenient "#!/usr/bin/env bash" which will also work if you
force bash's install into /bin.

However, you don't need to execute a shell script written for sh
from inside sh. It's just important that the following conditions
are met: (1st) "#!/bin/sh" is the first line, (2nd) the script is
executable (use "chmod +x <name>" to set the x bit), and (3rd) the
script is at a location inside $PATH, the search path from where
executables are sourced. When you run csh, give the "rehash" command
after you've put something into a valid executable location, or just
specify the full path (use "./name" or "./name.sh" for the current
directory).

[Baho Utot]

Post by Polytropon
I'm not sure if it has been mentioned in an explicit way, so

Post by Baho Utot
login in as a user ( non root )
set
SHELL is set to SHELL=/bin/sh
Ok now try
su - (give password)
set
SHELL=/bin/csh Ok that makes sense
Now
/bin/sh
set
SHELL=/bin/csh WTF?

This is to be expected. The variable $SHELL corresponds to the
"shell" field of /etc/passwd, which sets the login shell. When
you use "su -", you perform a login operation, so root gets
assigned the login shell as specified by /etc/passwd.
Additionally, "su -" sets the environmental variables for the
root user and therefore overwrites possibly different settings
of the initial user; "su -m" preserves that user's environment.

Post by Baho Utot
login as root
set
SHELL=/bin/csh Ok that makes sense
/bin/sh
set
SHELL=/bin/csh WTF?

Again, the same thing happens. If you execute /bin/sh, it will
inherit the environment previously set up by /bin/csh, which
also contains the $SHELL variable.
Remember, $SHELL does not state which shell you are currently
using - instead, it contains the name of the login shell.

Post by Baho Utot
It looks to me ( if I am not missing something here )
That I can only get to sh by loging in as a user...Again WTF

If you want to interactively run sh (the Bourne shell equivalent
of FreeBSD, which is not a good dialog shell, but the system's
default scripting shell, as well as the dialog shell for the
limited maintenance mode / single user mode), just execute it.
% sh
# _
For scripting use, /bin/sh is recommended over bash except you
really _really_ want to use bash-isms that sh does not implement.
In this case, make sure your script starts with "#!/usr/local/bin/bash"
(the default path after installation of bash from ports) or the
more convenient "#!/usr/bin/env bash" which will also work if you
force bash's install into /bin.
However, you don't need to execute a shell script written for sh
from inside sh. It's just important that the following conditions
are met: (1st) "#!/bin/sh" is the first line, (2nd) the script is
executable (use "chmod +x <name>" to set the x bit), and (3rd) the
script is at a location inside $PATH, the search path from where
executables are sourced. When you run csh, give the "rehash" command
after you've put something into a valid executable location, or just
specify the full path (use "./name" or "./name.sh" for the current
directory).

Looks like I need to reread how login/interactive shells are executed as
I don't remember when .profiles and .shrc are executed/read

[Polytropon]

Post by Baho Utot
Looks like I need to reread how login/interactive shells are executed as
I don't remember when .profiles and .shrc are executed/read

Oh, that's quite simple, if I remember correctly:

For the C shell:
/etc/csh.cshrc = global resource for all shells
/etc/csh.login = global "auto-exec" for login shells
/etc/csh.logout = global "auto-exec" at logout
~/.cshrc = user resource for all shells
~/.login = user "auto-exec" for login shells
~/.logout = user "auto-exec" at logout

In .cshrc, you often find "if ($?prompt) then ... endif" blocks
which make settings apply only for interactive shells (such as
keyboard definitions, history settings or other things that do
not matter for scripting); in such cases, $prompt is set.

For sh:
/etc/profile = global resource for interactive shells
~/.shrc = global resource for all shells
~/.profile = user resource for interactive shells

For bash:
~/.bashrc = user resource for all shells
~/.bash_profile = same as .profile, but bash-specific

Confusing... I hope I got it right this time. :-)

Note that bash also reads sh's profile files. The files are in
the corresonding shell's language. There also is a precedence in
which order the files are read.

Even though "read" and "execute" means the same for those files,
there are suggestions to use, for example, .cshrc for settings
such as prompt, history, aliases, path, mail ("internal stuff"),
while .login is used to start actual programs, such as biff,
mesg, fortune ("external stuff").

See "man csh", "man sh" and "man bash" for details. They contain
more information about when a shell is considered an interactive
or a login shell.

[David Christensen]

Post by Baho Utot
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script to
build some ports. That's were the trouble lies. ie functions not
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator

If I run your code on my FreeBSD 10.1 box with Csh login shell:

***@p42800e:~/sandbox/sh % uname -a
FreeBSD p42800e 10.1-RELEASE-p35 FreeBSD 10.1-RELEASE-p35 #0: Sat May
28 03:02:45 UTC 2016
***@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
***@p42800e:~/sandbox/sh % echo $SHELL
/bin/csh
***@p42800e:~/sandbox/sh % cat baho-utot.sh
#!/bin/sh

func() {
echo "Yep it's me"
return 1
}

if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi
***@p42800e:~/sandbox/sh % ./baho-utot.sh
This works


I do not see the string "Yep it's me".


I see the string "This works".


I do not see an error message.


I get the same results if I change my login shell to Sh:

$ echo $SHELL
/bin/sh
$ ./baho-utot.sh
This works


Enabling the -v and -x options for Sh provides a clue -- 'func' is not
getting called:

$ echo $SHELL
/bin/sh
$ /bin/sh -v -x baho-utot.sh
#!/bin/sh

func() {
echo "Yep it's me"
return 1
}

if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi
+ [ func ]
+ echo 'This works'
This works


Calling 'func' and then testing '$?' (exit value special variable)
explicitly seems to help:

$ cat baho-utot-2.sh
#!/bin/sh

func() {
echo "func returning 1"
return 1
}

func2() {
echo "func2 returning 0"
return 0
}

func
if [ $? = 1 ] ; then
echo "func worked"
else
echo "func did not work"
fi

func2
if [ $? = 1 ] ; then
echo "func2 worked"
else
echo "func2 did not work"
fi
$ ./baho-utot-2.sh
func returning 1
func worked
func2 returning 0
func2 did not work


David

[Baho Utot]

Post by David Christensen

Post by Baho Utot
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script to
build some ports. That's were the trouble lies. ie functions not
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator

FreeBSD p42800e 10.1-RELEASE-p35 FreeBSD 10.1-RELEASE-p35 #0: Sat
May 28 03:02:45 UTC 2016
/bin/csh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
This works
I do not see the string "Yep it's me".
I see the string "This works".
I do not see an error message.
$ echo $SHELL
/bin/sh
$ ./baho-utot.sh
This works
Enabling the -v and -x options for Sh provides a clue -- 'func' is not
$ echo $SHELL
/bin/sh
$ /bin/sh -v -x baho-utot.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
+ [ func ]
+ echo 'This works'
This works
Calling 'func' and then testing '$?' (exit value special variable)
$ cat baho-utot-2.sh
#!/bin/sh
func() {
echo "func returning 1"
return 1
}
func2() {
echo "func2 returning 0"
return 0
}
func
if [ $? = 1 ] ; then
echo "func worked"
else
echo "func did not work"
fi
func2
if [ $? = 1 ] ; then
echo "func2 worked"
else
echo "func2 did not work"
fi
$ ./baho-utot-2.sh
func returning 1
func worked
func2 returning 0
func2 did not work

Ok Thanks I'll give it a go

[RW via freebsd-questions]

On Sun, 5 Jun 2016 13:15:25 -0400

Post by Baho Utot

Post by David Christensen
...
...

Post by Baho Utot
shell /bin/csh

...

Post by Baho Utot
tcsh 6.18.01

...

Post by Baho Utot
OK tcsh as I thought

...

Post by Baho Utot
OK switch shells
# set

...

Post by Baho Utot
Why is the SHELL variable still set to /bin/csh

...
Because you are invoking a program (/bin/sh) and that program did
not modify the SHELL environment variable.

Post by Baho Utot
Do I understand correctly that you want bash to be your shell?
If so, you can run (as root), the command
chsh <username>

+1
https://www.freebsd.org/doc/en/articles/linux-users/shells.html
David

I understood that, But I do not want to change the default shell.
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script
to build some ports. That's were the trouble lies. ie functions not

It doesn't work because the shell script is wrong. [ func ] doesn't
execute func. func and "]" are actually arguments to "[". Using
backticks around func executes it.


See man test for the rest.


$ cat /tmp/foo
#!/bin/sh

func() {
echo "Yep its me"
return 1
}

if ! func ; then
echo "This works"
fi


if [ "`func`" = "Yep its me" ] ; then
echo "This works too"
fi


if [ "`func`" ] ; then
echo "And this works also"
fi

$ /tmp/foo
Yep its me
This works
This works too
And this works also

Post by Baho Utot
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to

[jd1008]

Guys, in shell semantics, a command returning non zero indicates some
failure,
whereas a command returning 0, indicates success.
This is the convention.

Post by David Christensen

Post by Baho Utot
I only want to create a script ( sh script ) and run if from a clean
machine with just base install nothing else and then run my sh script to
build some ports. That's were the trouble lies. ie functions not
test.sh
chmod +x test.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq func
] doesn't work either
echo "This works"
fi
./test.sh
[: func: unexpected operator

FreeBSD p42800e 10.1-RELEASE-p35 FreeBSD 10.1-RELEASE-p35 #0: Sat
May 28 03:02:45 UTC 2016
/bin/csh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
This works
I do not see the string "Yep it's me".
I see the string "This works".
I do not see an error message.
$ echo $SHELL
/bin/sh
$ ./baho-utot.sh
This works
Enabling the -v and -x options for Sh provides a clue -- 'func' is not
$ echo $SHELL
/bin/sh
$ /bin/sh -v -x baho-utot.sh
#!/bin/sh
func() {
echo "Yep it's me"
return 1
}
if [ func ] ; then # if [ 1 = func ] or if [ 1 -eq
func ] doesn't work either
echo "This works"
fi
+ [ func ]
+ echo 'This works'
This works
Calling 'func' and then testing '$?' (exit value special variable)
$ cat baho-utot-2.sh
#!/bin/sh
func() {
echo "func returning 1"
return 1
}
func2() {
echo "func2 returning 0"
return 0
}
func
if [ $? = 1 ] ; then
echo "func worked"
else
echo "func did not work"
fi
func2
if [ $? = 1 ] ; then
echo "func2 worked"
else
echo "func2 did not work"
fi
$ ./baho-utot-2.sh
func returning 1
func worked
func2 returning 0
func2 did not work
David
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
.

[David Christensen]

Post by jd1008
Guys, in shell semantics, a command returning non zero indicates some
failure,
whereas a command returning 0, indicates success.
This is the convention.

Agreed, but we were already barking up the wrong side of the road. ;-)


David

[Kevin P. Neal]

Post by Baho Utot

Post by Ernie Luzar
Place your script in /usr/local/bin on your development pc and on the
new installed os pc. Then just entering the script on the console
command line will cause it to execute. BY the way your script doesn't
need to be suffixed with .sh to work.

It does need the suffix .sh because if it is missing I fail to
function...... the computer does just fine.

No, if this is the case you are doing something weird. The filename does
not matter, and the extension is just part of that filename.

A shell script should start with the "#!" line (the "shebang" line) as the
very first line, and it should have the executable bits set. It will then
run with the interpreter specified in the initial shebang line. That is,
when run from a command line. And it must be either in your path or have
the path to it specified (like the "./" prefix mentioned earlier in the
thread assuming the script is in the current directory).

If you run a shell script by giving it as an argument to an invocation of
a shell command then you are bypassing both the shebang line and the
executable bits. This will tend to give surprising results. Don't do that.

[Jon Radel]

Post by Kevin P. Neal

Post by Baho Utot
It does need the suffix .sh because if it is missing I fail to
function...... the computer does just fine.

No, if this is the case you are doing something weird. The filename does
not matter, and the extension is just part of that filename.

Perhaps you should read what he wrote again? He's already agreed that FreeBSD doesn't need the extension. It's more a personal problem--I can only surmise he confuses himself less when he labels his files with hints as to their type.

:-/

--Jon Radel

[krad]

no its a pkg/port

Post by Manas Bhatnagar
bash isn't installed by default on FreeBSD
Original Message
Sent:June 5, 2016 12:02
Subject:Re: sh[it] and What am I missing here?

Post by Manas Bhatnagar

Post by Baho Utot
After the /bin/sh am I into a bourne shell or what?

Try 'env bash'?

env: bash: No such file or directory
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "

[Baho Utot]

Post by Jon Radel

Post by Kevin P. Neal

Post by Baho Utot
It does need the suffix .sh because if it is missing I fail to
function...... the computer does just fine.

No, if this is the case you are doing something weird. The filename does
not matter, and the extension is just part of that filename.

Perhaps you should read what he wrote again? He's already agreed that FreeBSD doesn't need the extension. It's more a personal problem--I can only surmise he confuses himself less when he labels his files with hints as to their type.
:-/
--Jon Radel

Yep you got it....When I see .sh I know it's a shell script

[Baho Utot]

Post by Kevin P. Neal

Post by Baho Utot

Post by Ernie Luzar
Place your script in /usr/local/bin on your development pc and on the
new installed os pc. Then just entering the script on the console
command line will cause it to execute. BY the way your script doesn't
need to be suffixed with .sh to work.

It does need the suffix .sh because if it is missing I fail to
function...... the computer does just fine.

No, if this is the case you are doing something weird. The filename does
not matter, and the extension is just part of that filename.
A shell script should start with the "#!" line (the "shebang" line) as the
very first line, and it should have the executable bits set. It will then
run with the interpreter specified in the initial shebang line. That is,
when run from a command line. And it must be either in your path or have
the path to it specified (like the "./" prefix mentioned earlier in the
thread assuming the script is in the current directory).
If you run a shell script by giving it as an argument to an invocation of
a shell command then you are bypassing both the shebang line and the
executable bits. This will tend to give surprising results. Don't do that.

Are you saying the following is bad?

sh my.fault

I always use this layout

cat my.fault.sh

#!/bin/sh
# Do a bunch of stupid things
.....
# Then try to figure out what happened
....
printf "%s\n" "Run Complete"

BTW are you Cowboy Neal?

[Kevin P. Neal]

Post by Baho Utot

Post by Kevin P. Neal

Post by Baho Utot

Post by Ernie Luzar
Place your script in /usr/local/bin on your development pc and on the
new installed os pc. Then just entering the script on the console
command line will cause it to execute. BY the way your script doesn't
need to be suffixed with .sh to work.

It does need the suffix .sh because if it is missing I fail to
function...... the computer does just fine.

Ah, when you said "I fail to function" you meant you the person, not you
the script. My misunderstanding.

Post by Baho Utot

Post by Kevin P. Neal
No, if this is the case you are doing something weird. The filename does
not matter, and the extension is just part of that filename.
A shell script should start with the "#!" line (the "shebang" line) as the
very first line, and it should have the executable bits set. It will then
run with the interpreter specified in the initial shebang line. That is,
when run from a command line. And it must be either in your path or have
the path to it specified (like the "./" prefix mentioned earlier in the
thread assuming the script is in the current directory).
If you run a shell script by giving it as an argument to an invocation of
a shell command then you are bypassing both the shebang line and the
executable bits. This will tend to give surprising results. Don't do that.

Are you saying the following is bad?
sh my.fault

Best case it is perhaps extra typing.

Worst case the shell you happen to use isn't the one needed by the script
and the script goes off the rails.

Post by Baho Utot
I always use this layout
cat my.fault.sh
#!/bin/sh
# Do a bunch of stupid things
.....
# Then try to figure out what happened
....
printf "%s\n" "Run Complete"

Yup, that's the preferred layout.

Post by Baho Utot
BTW are you Cowboy Neal?

No.