Questiion regarding potential length of input into a variable

Hmm, maybe some weird default. Every user has their own shell assigned. If not, it uses the system’s default shell.

I’ve just written the following quick script for you to check the default shell for any user by querying /etc/passwd.

#!/bin/bash
#########################################################################
# Copyright (C) 2022 Akito <the@akito.ooo>                              #
#                                                                       #
# This program is free software: you can redistribute it and/or modify  #
# it under the terms of the GNU General Public License as published by  #
# the Free Software Foundation, either version 3 of the License, or     #
# (at your option) any later version.                                   #
#                                                                       #
# This program is distributed in the hope that it will be useful,       #
# but WITHOUT ANY WARRANTY; without even the implied warranty of        #
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the          #
# GNU General Public License for more details.                          #
#                                                                       #
# You should have received a copy of the GNU General Public License     #
# along with this program.  If not, see <http://www.gnu.org/licenses/>. #
#########################################################################


user="$1"

[[ -z "$user" ]] && \
echo "You must provide a user as the first argument to this script!" && \
exit 1

passwd="$(</etc/passwd)"
passwd_entry_user="$(grep "$1" <<<"${passwd}")"

[[ $? != 0 ]] && \
echo "Provided user does not exist!" && \
exit 1

printf '%s\n' "${passwd_entry_user##*:}"
1 Like

@Akito
I will test it

[nevj@trinity ~]$ ./chkshell.sh nevj
/bin/bash
[nevj@trinity ~]$ ./chkshell.sh root
/bin/sh

Yes it works, but not under sh

# sh -e ./chkshell.sh nevj
./chkshell.sh: 22: [[: not found
./chkshell.sh: 27: Syntax error: redirection unexpected

I guess its not a valid sh script?
Neville

Hi, Neville, :wave:

thanks so much. :heart:

Yes, you solved it. Great.:+1:

I tried it out and it works superbly. Now I wanted to get it going in the fish shell, too.
Here it works thus:
sed "/^ *\$/d" txt
In this case the backslash before the dollar-sign is needed.

Thank you very much for providing some awk examples. :heart:

rmnull.awk I understand. It works splendidly as well.

Alas sum.awk and cut.awk already seem to be beyond my grasp.
Sorry, Neville. :slightly_frowning_face:

That I believe. :wink:

One thing I noticed when running awk -f rmnull.awk txt: The awk-script runs successfully with standard permissions:
-rw-r--r-- 1 rosika2 rosika2 28 Apr 6 14:59 rmnull.awk

Is there no need to make it executable like bash-scripts :question:

Many thanks again for providing some introductory examples, Neville.

Cheers from Rosika :slightly_smiling_face:

1 Like

@Akito:

Thanks a lot for your great input.
I´ll try to have a closer look at your fantastic work here.

Many greetings.
Rosika :slightly_smiling_face:

1 Like

No, no need. It is just a file read by awk. It is awk itself that is executing.

If you want to go further with awk find a tutorial on the web
Those $1,$2, etc are first field, second field, etc on each line
Awk divides each line into fields
For a text file fields are words, so that first script works by checking if there is a word on the line.
For a data file, a field is a data item separated by blanks or tab. The second and third scripts are for data files.

If you needed to backslash the $ in fish it suggests the " " are not protecting the sed command from the shell.

Regards
Neville

1 Like

Hi Neville, and thanks a lot for your explanations, :wave:

O.K. That makes sense. I should´ve looked at:

whatis awk
awk (1)              - pattern scanning and text processing language

Well, coming from bash-scripting (I´m just dabbling :blush:) I was under some misapprehension it seems.

Right. I certainly should have known this one as I used it at some time in the past: :wink:

lscpu | grep MHz 
CPU MHz:                         1596.388

lscpu | grep MHz | awk '{print $3}'
1600.048

I see. That was the part which was new to me. Thanks for explaining.

O.K.

For the fish-shell:

Without the backslash I get an error:

sed "/^ *$/d" txt.txt
fish: $/ is not a valid variable in fish.
sed "/^ *$/d" txt.txt
          ^

… with the backslash:

sed "/^ *\$/d" txt.txt
bs
dfgh
gh

But I just found out that single quotation marks work as well (in this case: no backslash is needed):

sed '/^ *$/d' txt.txt
bs
dfgh
gh

Many thanks again, Neville, for taking the time to provide these explanations.

Many greetings from Rosika :slightly_smiling_face:

1 Like

So in fish single quote is more powerful than double quote in protecting strings from the shell
but
in bash double quote is more powerful than single quote.

No wonder people have trouble with shells

Regards
Neville

1 Like

Thanks, Neville, for putting things into perspective. :+1:
I never knew this difference. One never stops learning. :blush:

Just to clarify, if you don´t mind my asking:

By “protecting strings from the shell” do you mean the way how a certain input is handled by the shell?

Cheers from Rosika :slightly_smiling_face:

Sure Rosika,
If you have some part of a command not quoted, the shell will act on any regex characters in it, before it is passed on to sed or awk or whatever.
So a * for example will be replaced by a list of all the filenames in the directory , and then that list will be passed on.
To stop the shell getting in first , when there are regex characters in the command, you quote it. The quotes protect it from being interpreted as a regular expression by the shell.
Unfortunately various shells react differently to the two types of quotes.

I am sorry that is complicated.
It is all because the shell gets to see what is on each line, before any commands on the line get to see it. So the shell can get in first and modify it. You may not want that so you use quotes. The shell is not supposed to look inside the pair of quotes. That is what I mean by protecting.

This is one of the worst issues with shellscripts. Master this and you are an expert.

Regards
Neville

1 Like

Thanks so much, Neville, for elaborating on the theoretical - and indeed practical - aspects of how the shell deals with input.
You´re too kind. :heart:

Yes, I think I get it. That´s what you mean when you say “protecting strings from the shell”.

O.K. Understood.
You put it quite eloquently. :+1:

Yes, that´s why the fish-shell needs the single quotes, methinks.

No need to be sorry, dear Neville, I get it now and that makes it less complicated to me.
So I keep adding to my modest knowledge base.

Thanks again a thousand times. :smiley:
Your help is highly appreciated.

Many greetings from Rosika :heart:

2 Likes

@Rosika
Commonly known as the doll book
The Unix System by SR Bourne
you might find it in the library
He was the author of the sh shell
Neville

PS That book might be hard to find.
I have two original BSD Unix documents on shell usage. They are here

sh.nroff is a Bourne’s original article on the sh shell. I translated it from nroff to a pdf file bsdsh.pdf

bsdcsh.pdf is William Joy’s original article on the csh shell

Both contain useful introductions to metacharacters.

Can anyone point to a comparable document for bash shell? Preferably by the original author.

Neville

Hi, dear Neville, :wave:

thank you so much for the link to your github page. I´m so impressed. :+1:

That´s great. I just dowloaded it for having it available as a reference. I´ll also plan to read it through as soon as possible.

bsdcsh.pdf: I´ll look into that as well. :blush:

That´d be interesting. Alas cannot be not helpful with this one but perhaps some of the other knowledgeable people here might have some input…

As an afterthought;

For the fish-shell (if anyone is interested) an extensive documentation may be found here:
Introduction — fish-shell 3.7.0 documentation .

Thanks again so much, Neville, for your kind help.
Many greetings.
Rosika :slightly_smiling_face:

1 Like

Looks like fish has better documentation than most shells
Thanks Roseka
Neville

Bash shell documentation is here. Bash is a GNU product

1 Like

Hi Neville, :wave:

Yes, I think the documentation is quite extensive.

Plus: With the installation of fish you get the whole documentation-bundle installed locally. :smiley:
Just type “help” into your terminal and your browser automatically opens up the page

  • file:///usr/share/doc/fish/index.html # starting page

Another example:

  • file:///usr/share/doc/fish/fish_for_bash_users.html?highlight=command%20substitution # info on command substitution

This may come in handy for people who have to watch their data usage… :blush:

Many greetings
Rosika :slightly_smiling_face:

P.S.:

Thanks a lot for the link to the Bash Reference Manual.
It certainly took some time and effort to research it. :+1:

1 Like

That brings back memories.
With FreeBSD all the Unix documents came with the installation. That is where those sh and csh documents came from, from archives of FreeBSD files.
Linux does not seem to have acquired that feature. It relies on web documents. Julia is even more extreme - its libraries of packages dont even install… all packages and docs are on github.

Neville

1 Like

Hi Neville, :wave:

Sounds interesting. Is this still the case today?
And is it also true for other BSD distros (e.g. OpenBSD)?

I´m asking because I´d like to try a version of BSD in a VM one fine day. :blush:

Well, I hadn´t heard of julia before. So I looked it up…

env LANG=en_US.UTF-8 apt-cache show julia
[...]
Julia is a high-level, high-performance dynamic programming language for
 technical computing, with syntax that is familiar to users of other technical
 computing environments.
[...]

Thanks so much for the info.

Many greetings.
Rosika :slightly_smiling_face:

Can not answer that. 15 years since I used BSD.
Will do some research. I have a live FreeBSD DVD. Will look there.

You used to be able to download the entire sourcecode of FreeBSD, and have it appear in the src directory. That is what src used to be for. You could compile it from there and make a new kernel.

I do know , most of the BSD’s use only ZFS filesystem. That is a barrier for me today. All my files are on ext4 partitions. I could not access my files.

A compromise is Void. It is a BSD / Linux hybrid. It can read ext4.

Regards
Neville

1 Like

Thanks a lot, Neville, for your answer. :heart:

Oh, now I feel really bad.
I certainly didn´t want to give you any trouble in doing more work on my behalf than you already have. :slightly_frowning_face:
Perhaps I can do some research on that…

Thanks also for the additional info about the ZFS filesystem. :smiley:

I see. Well, that´s good to know. Thanks a lot.

Many greetings
Rosika :slightly_smiling_face:

No No. I enjoy this.
This seems to imply that the bsd docs are still part of freebsd
https://people.debian.org/~adamm/doc/

Neville

1 Like

Hi Neville, :wave:

You´re too kind. Thanks a lot. :blush:

And thank you for the link. :heart:

[…] the 4.4BSD Lite Documents which are part of the FreeBSD operating system

It really seems the docs are part of the os. Well, that´s really great.
As I mentioned earlier: for people with limited data download (and upload) that should be a treat.

Thanks again for your investigating the matter.
Many greetings and have a nice weekend.
Rosika :slightly_smiling_face: