-4

I'm trying to accomplish a multiple option text-based story, based on various user inputs. Though this seems like a fun project to test various statements, and begin scripting with the VI Editor. (Not trying to be super tech-savvy, nor am I experienced with scripting).

So here is what I got:

enter image description here

However; I can't get the last echo statement to produce results, as this is what comes up:

enter image description here

I tried using a '0' (digit) for the 'input_user_name', this way in the 'if' statement so it would be a number instead of a letter, but to no avail. Not really sure what's wrong (sigh). It's probably a super easy fix (I'm guessing).

steve
  • 21,892
bmwd Gaming
  • 1

4 Answers4

3
if ($input_user_name == 'n'); ...

The parenthesis are used for command grouping, which isn't very useful in the if statement. (Unless you want a subshell for some reason.) In practice, this is the same as if $input_user_name == 'n';, and that expands input_user_name, splits and globs the result, and runs it as a command. You entered Bruce, the shell runs the command Bruce.

ilkkachu
  • 138,973
0

I made a few assumptions in this, but I have modified your code to the following:

#! /bin/bash -
clear
echo -e "\nWelcome, $(whoami)\nShall we change this to something more appropriate?"
read -rp "If not enter input 'n' and press [ENTER] " input_user_name

if [[ "$input_user_name" == 'n' ]]; then
        user_name="$(whoami)"
else
        user_name="$input_user_name"
fi

echo "You are ${user_name}!"

I've changed your first few echo lines into a single echo -e line which allows the use of special characters such as newline \n, tab \t, and some others.

I've also changed your read statement into a single line and added the -r switch which will prevent it from destroying any backslashes.

You were getting the error on line 10 because you were not doing a legitimate test. You need to use brackets [ or preferably [[ instead of parenthesis.

Also in shell/bash syntax you cannot put a space in variable assignments that way. It needs to be:

variable=value

NOT

variable = value

OR

$variable = value

etc

jesse_b
  • 37,005
  • Sincerely thank you. This helps clarify some of the other previous 'echo' statements I've seen on other sites, as they included the -e switch too. Extremely new to all this so every bit of information, especially laid out with clarity, helps a ton! – bmwd Gaming Dec 09 '17 at 21:50
0

use square brackets [ ] instead of ( ) 

#!/bin/bash
set +x


clear
echo
echo "Welcome, $(whoami)"
echo

echo "Shall we change this to something more appropriate?"
echo "if no,simply enter 'n' then press [Enter]:"
read input_user_name

if [ $input_user_name == "n" ];
then user_name=`whoami`   ## i have used `` to get the value of whoami
else

user_name=$input_user_name
fi

echo "Your $user_name !"

output :

Welcome, vikasven

Shall we change this to something more appropriate?
if no,simply enter 'n' then press [Enter]:
Vikas
Your Vikas !
Vikas Venna
  • 13
-3

Change then user_name = $whoami to then user_name=$(whoami)

fpmurphy
  • 4,636
  • This still wouldn't work. It would need to be: user_name=$(whoami) but should be: user_name="$(whoami)" – jesse_b Dec 09 '17 at 20:43
  • Oh why? In the OP's example, whoami returns bdraper, i.e. effective userid. No spaces in that string. Assigning a string without spaces and double quotes have been perfectly valid in shells since the earliest Unix shell. – fpmurphy Dec 09 '17 at 20:55
  • No they haven't and no it doesn't...they have been perfectly valid in shells that begin with the word "power". In OP's example echo "Welcome, $(whoami)" works fine as it should. None of his variable assignments work except for the read statement. – jesse_b Dec 09 '17 at 20:56
  • @Jesse_b. Strange, user_name=$(whoami); echo $user_name works perfectly well for me and returns the expected result. – fpmurphy Dec 09 '17 at 21:02
  • That isn't strange. That is exactly what I had suggested in my first comment. Except now you are introducing security and functionality issues by not double quoting it... – jesse_b Dec 09 '17 at 21:04
  • I get the feeling you don't really care but in case you wanted to read up on it: https://github.com/koalaman/shellcheck/wiki/SC2086 – jesse_b Dec 09 '17 at 21:10
  • 1
    @Jesse_b I am afraid you are mistaken :) Word-slitting is NOT done when assigning to a variable. So this: var=$(some cmd) or var=$other_var is absolutely fine. However, in mere expansion, for example: echo "$var", quotes are necessary, of course. – PesaThe Dec 10 '17 at 00:55
  • 1
    @Jesse_b If you are skeptical about this, I will quote bash manual for you: "The text after the ‘=’ in each variable assignment undergoes tilde expansion, parameter expansion, command substitution, arithmetic expansion, and quote removal before being assigned to the variable." - no word-splitting. – PesaThe Dec 10 '17 at 01:00
  • https://stackoverflow.com/a/37932117/8239155 Honestly with the whoami command it probably wouldn't be an issue but I'm sure someone can find a way to make a malicious username or something, so no, unless you have a good reason to not quote, you should in fact quote. – jesse_b Dec 10 '17 at 01:02
  • 1
    @Jesse_b Yes, indeed, you proved my point. I just wanted to point out, even though this answer does not answer the problem whatsoever, that user_name=$(whoami) does not create, quoting your comment, security and functionality issues. – PesaThe Dec 10 '17 at 01:06
  • 1
    @Jesse_b Did you read the answer you posted? Variable assignment creates a “double quote context”. I will say it once more. You do not need quotes when assigning to a variable. var=$(cmd) is basically treated as if it were quoted like this: var="$(cmd)". – PesaThe Dec 10 '17 at 01:15
  • Did you read it? What about dash? or the several other caveats that probably would never be an issue but still make this argument pointless...just quote it period – jesse_b Dec 10 '17 at 01:18
  • 1
    @Jesse_b And is OP using dash? No. He is in fact using bash. You should use features available in the shell you are using. It's like saying: never use [[ ]] because it does not exist in sh!!! You see my point? Don't tell someone something is incorrect when it is not. – PesaThe Dec 10 '17 at 01:23
  • You can do whatever you want. I will recommend to OP that, especially as someone new to scripting, he always quote any command substitution unless he has a reason not to, and understands that reason. – jesse_b Dec 10 '17 at 01:27
  • 2
    @Jesse_b And you still don't get what I am trying to say. It's a fine recommendation, quote if you like, I myself think it is better, more foolproof. But don't tell someone it is incorrect when unquoted. You are presenting false information to them. – PesaThe Dec 10 '17 at 01:29