LinuxQuestions.org - Batch files on linux?

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - Batch files on linux? (https://www.linuxquestions.org/questions/linux-newbie-8/batch-files-on-linux-547839/)

Batch files on linux?

I need to create batch file on linux but no idea how to do it.
On dos/windows system it enough to write commands in notepad and then save file as bat.
How that going in linux?Is it same?
I have batch file with following commands:
mkdir directory
cp *.* dir1 dir 2
cp *.* dir1 dir 3
cp *.* dir1 dir 4
cp *.* dir1 dir 5
cp *.* dir1 dir 6
cp *.* dir1 dir 7
Now how tu run that file.

Hi,

You can put all the commands in a file and parse it. I.e:

After putting your example commands in a file (called mkcp in this example), you can do the following from the command line:

. mkcp That's a dot followed by a space and the name of the file.
All the commands inside the file are executed relative to the dir you are in.

You can also make it a script by placing this #!/bin/bash as the first line, make it executable (chmod 755 <filename>) and execute it (./<filename>).

Hope this helps.

Erhm. Actually .. you pretty much *have to* specify

Code:

#!/usr/bin/env bash

on the first line. Otherwise you're just trying to execute a text file.

Hi,

@introuble: No you don't :)

Without the hash-bang commands are executed in the current shell, with a hash-bang commands are executed in a new (child) shell.

Code:

$ ls -l tester

-rw-r--r--  1 druuna  druuna  38 Apr 21 22:29 tester

$ 

$ cat tester

ls -l



chmod 444 tester



ls -l tester

$

$ . tester

total 4292328

drwxr-xr-x  4 druuna  druuna        136 Apr 21 01:08 XXXXX

-rw-r--r--  1 druuna  druuna        38 Apr 21 22:29 tester

-rw-r-----  1 druuna  druuna  734230528 Apr 16 15:29 the.fountain.avi

-rw-------  1 druuna  druuna  731729920 Apr 20 18:36 torchwood.s01e12.avi

-rw-------  1 druuna  druuna  731695104 Apr 20 18:37 torchwood.s01e13.avi

-r--r--r--  1 druuna  druuna  38 Apr 21 22:29 tester

As the above example shows, the commands inside tester are executed. No need for the #!/bin/bash line.
The lines are given to the shell one at the time and executed as 'one-liners'. But this is just 'dumb' shell behavior and has its limits.

An example of different behavior:
Put an exit in tester and the shell exits, not the tester file. If it would be a real script (including the hash-bang line) the script would exit, not the shell you ran it from.

Hope this clears things up a bit.

Hi.

Suppose you have a file like this:

Code:

# @(#) s4      Demonstrate command file, omitting shebang line.



echo " Hello, world."

In a script file, lines that begin with a "#" are comments. Empty lines can be added for readability.

In this example, the command echo is basically a print statement. The text string on the line will be sent to the terminal output device.

There are a number of ways to get commands in a file executed. You can try the illustrations below for yourself. (I did a lot of copying and pasting, but I think the actions and the responses are in the correct order.)

The permissions on a file can be important. The permissions of this file can be seen with a command like:

Code:

ls -l s4

which produces this cryptic output:

Code:

-rw-r--r-- 1 makyo makyo 82 Apr 21 17:27 s4

which, you will learn, means that you have read and write permission for this file, denoted by the first "rw" on the line.

As to how you can execute the commands in this file, you could try (case 1):

Code:

./s4

which produces:

Code:

bash: ./s4: Permission denied

you could also try (case 2):

Code:

. s4

producing:

Code:

Hello, world.

and you could also do (case 3):

Code:

sh s4

giving you:

Code:

Hello, world.

Making the file executable for yourself with:

Code:

chmod +x s4

ls -l s4

producing (note the addition of "x", for executable):

Code:

-rwxr-xr-x 1 makyo makyo 82 Apr 21 17:27 s4*

would allow case 1 to succeed:

Code:

$ ./s4

 Hello, world.

(The "$ " is a prompt, and the "./" part means "the file in the current directory".)

I usually make the first line in my file a special line, so that my script files look like:

Code:

#!/bin/sh



# @(#) s4      Demonstrate command file, omitting shebang line.



echo " Hello, world."

There are variations, and note the comments from druuna about shells.

Best wishes ... cheers, makyo

(edit 1, 2: typos )

It was enough to chmod file and it was working hehe

By the way, it's not necessary or advisable to use '*.*' as on Linux files may or may not have file extensions. You want to just use '*' instead.

@ druuna:

Quite odd. I distinctly remember doing something like:

Code:

echo "mkdir test" >> something && . something

and receiving an error. Tried your tester script and it works fine. Aaanywho. I didn't know of this feature so far. Does it have any actual use over let's say a regular shell script?

Quote:

Originally Posted by introuble

@ druuna:

Quite odd. I distinctly remember doing something like:

Code:

echo "mkdir test" >> something && . something

and receiving an error. Tried your tester script and it works fine. Aaanywho. I didn't know of this feature so far. Does it have any actual use over let's say a regular shell script?

No advantages so far. Just different ways to do the same thing.
"." or "source" allows you to set up "general variables" into your script
Ciao

Quote:

Originally Posted by introuble

@ druuna:

Quite odd. I distinctly remember doing something like:

Code:

echo "mkdir test" >> something && . something

and receiving an error. Tried your tester script and it works fine.

That is odd, I just tried your example and it works fine on this side (no error(s) and test is created). Did you have permissions to create that test directory??

Quote:

Aaanywho. I didn't know of this feature so far. Does it have any actual use over let's say a regular shell script?

Depending on the situation it's sometimes preferable to source a file instead of running a script. Sourcing will happen in the current shell (example: set some variables that can be used in that shell). You cannot do this with a script because the 'stuff' set in the script are gone (child shell) after it is finished.
Most 'stuff' that are 'always' used are sourced from /etc/profile (or the other login script), the (extended) PATH is an example of that, but every so often you need access to stuff that isn't needed on a daily base. It that case sourcing a specially created file will do the trick.

Hope this clears things up a bit.