[SOLVED] Bash script directly in terminal?

Weapon S · 02-18-2015, 04:33 AM

Is it possible to execute a shell script without first saving it into a file? If so, I'm not able to find the proper syntax on my own. I am able to make a script and then execute it. However I often find myself wanting to type things that aren't worth the trouble of saving even temporarily. F.i.:

Code:

for x in *.bar do foo $x done

millgates · 02-18-2015, 05:19 AM

You're going to need either newlines or semicolons.

Code:

for x in *.bar; do foo "$x"; done

veerain · 02-18-2015, 06:21 AM

You can run like this:

Code:

/bin/bash -c 'for x in *.bar; do foo "$x"; done'

rtmistler · 02-18-2015, 07:01 AM

Absolutely as per the examples shown or where in my case I have a bunch of txt files in a directory I can do:

Code:

for i in *.txt; do echo $i; done;

And this is the same as a "ls -1 *.txt" command.

What I always say is that "Whatever you can do in a command line, you can do in a shell script." Because that's what a shell script is.

However, I also do find that writing increasingly more complex stuff into just the command line becomes more of a hassle versus writing to a file and using that. Because over time, your scripts do more versus less. I also follow a template of sorts in that most/all of my scripts contain:

Code:

#/!bin/sh

#set -xv

And I either enable the set -xv or not depending on whether I wish debug while I run the script.

What I do is I have a sub-directory named "testcode" and I put in all experimentations there.

I keep that stuff, some of it is work efforts, some of it is efforts put forth here to answer a question, but it helps to recall and after all, even a 20-30 line script is just 500-600 BYTES, it's more worth it for me to save that stuff versus discard it.

See the "My Bash Blog" link in my signature for some script info.

Weapon S · 02-19-2015, 03:58 AM

I tried newline with an escape, but that didn't work, also the scripts I based my line on seemed to have superfluous newlines. Thanks for the answers.

rtmistler · 02-19-2015, 07:25 AM

Quote:

Originally Posted by Weapon S

I tried newline with an escape, but that didn't work, also the scripts I based my line on seemed to have superfluous newlines. Thanks for the answers.

This is why I do the exact opposite of what you originally said about not taking the time to write them into a file and just use the command line. They'll be easier to debug.

My first instinct was to ask if you are creating scripts from within Linux and using one of the common Linux text editors such as vi, gedit, emacs and to cite the for instance that I would not use LibreOffice Writer to create and edit a script.

However, you've said that you desire to put it all on the command line. Well ... why did you try to escape a newline and why did you think you needed to specifically add a newline? Proper end of lines would be the SEMICOLON.

I'll go back to my short example and show it as originally represented on one line and also as a file script, note the differences and the second variation which is allowable:

Code:

for i in *.txt; do echo $i; done;

One form of fully expanded out. Note that there are newlines, however no semicolon characters because they're not necessarily needed:

Code:

#!/bin/sh

for i in *.txt
do
    echo $i
done

A briefer form where I've pulled the "do" up to the "for" line, it does require a semicolon to satisfy the syntax. Meanwhile the semicolons after the echo and done statements are tolerated, but not necessary:

Code:

#!/bin/sh

for i in *.txt; do
    echo $i;
done;

Now here's an example of mistakes in the one-line and fully expanded scripts:

Code:

for i in *.txt; do echo $i done;
>

The result here is the command line dropped me to a continue line where it is expecting more shell input. It correctly detects that the command sequence is not complete so it's waiting for the remainder of that sequence. As a result, the writer of that line has just about zero feedback as to what the problem is. Now take that same single line script and make a mistake in the multi-line file script form:

Code:

#!/bin/sh

for i in *.txt; do
    echo $i done;

The result when trying to run this script is:

Code:

./test.sh: line 5: syntax error: unexpected end of file

It at least gives some impression of the error you made and points to the suspected line. But also as you can see, this particular complaint is beyond the last line of the script; still it allows you to then say "Perhaps the problem then is in line #4 ..."

pan64 · 02-19-2015, 09:03 AM

echo $i; done;
the missing ; causes a very tricky error, and as far as I know this kind of issues cannot be solved easily.
So:
echo $i done;
is completely correct, there is nothing wrong with it. Therefore the syntax checker will go further and try to find the end of the for loop (actually it would be the pair of the keyword do: done). But not found at all, therefore it will say: unexpected end of file.
Another possibility is (just for example) to write a never ending string (missing closing "):
echo "$i; done;
a good help is an editor using syntax highlight, because you will easily recognize the problem (in this case done will be colored as string, not as keyword). In such cases the syntax checker never can tell you what's wrong, just tell you something went wrong.

rtmistler · 02-19-2015, 09:13 AM

Quote:

Originally Posted by pan64

In such cases the syntax checker never can tell you what's wrong, just tell you something went wrong.

Yeah I picked a bad example, but then again it was a very limited script. This is all up to Weapon S really. I just felt they were being too limiting by trying to simplify the concept and write scripts on the command line. On one hand, if it's just a quick, nominal command, why not? On the other hand, are my variety of points about saving prior work, the fact that saving files isn't going to blow away storage space, and then the issues of debug

Quote:

Originally Posted by pan64

a good help is an editor using syntax highlight, because you will easily recognize the problem (in this case done will be colored as string, not as keyword).

Your recommendation? I use emacs and that does highlight, but I also name my scripts with .sh extension. Unsure if one has a file with no extension but which is a shell script, if it will auto-detect that. Mine did not when I gave it a brief try, although I suppose I could force the emacs mode to say it's a script.

pan64 · 02-19-2015, 09:31 AM

Quote:

Originally Posted by rtmistler

Your recommendation? I use emacs and that does highlight, but I also name my scripts with .sh extension. Unsure if one has a file with no extension but which is a shell script, if it will auto-detect that. Mine did not when I gave it a brief try, although I suppose I could force the emacs mode to say it's a script.

I use personally vim, and I set the type manually if vi cannot recognize. The main point is you need to be familiar with that colors, otherwise that will not say anything for you. I do not know emacs very well but I think it is as powerful as vi (or geany or - more or less - any other modern editor).

This saved me a lot of time hunting for that missing/mistyped character.