What is the equivalent of the DOS batch file?

[DxHum]

Is the equivalent a script file? If so, what do we use to write it?

 

[dos2unix]

there are a hundreds ways to do this, but I would usually it's bash shell script.

#!/usr/bin/bash
echo "Hello threre."
cp /usr/file1 /usr2

 

[DxHum]

there are a hundreds ways to do this, but I would usually it's bash shell script.

#!/usr/bin/bash
echo "Hello threre."
cp /usr/file1 /usr2

Well... I only know one; the one you mention now.

So how does it work? Do I create the script with an editor? If so, what is the extension under which to save the file when completed?

This is a tutorial I found. But while is talks about syntax and the correct way to write the script, it does not get into what to use as a script editor and the proper naming convention.

https://linuxconfig.org/how-to-write-a-bash-script-to-run-commands

 

[JasKinasis]

The equivalent to a DOS batch file would be a shellscript.
To create a shellscript, you can just use any text editor.
Whichever editor you use is completely up to you.

You could use editors like nano, vim, neovim, emacs, spacemacs, joe etc. in the terminal, or you could use a GUI based text editor - Kate, leafpad, gedit, gvim, Caja, the GUI version of emacs/spacemacs, neovim etc etc..

Whatever Linux distro you have installed, you will almost certainly have nano and vi pre-installed in the terminal. vi is just vim-minimal with the 'compatible' option turned on, which makes vim behave exactly the same as the classic vi. vi/vim aren't for everybody though. Personally, I love it.
But nano is probably the simplest terminal based text editor. So you might want to try nano.

Alternatively, your desktop environment should also have at least one GUI based text editor pre-installed. But exactly which one you have will depend entirely on the Desktop you have installed.

You could give your shellscripts a .sh extension, in order to identify them as shellscripts, but that is entirely optional. In Linux, we generally use a shebang line as the first line of our scripts, which tells the shell which interpreter to use to run a script.

So for a generic shellscript, we'd start our shellscript with a shebang like:

#!/bin/sh

or

#!/usr/bin/env sh

That tells the shell to use whatever the default minimal shell is. Very often sh just redirects to bash nowadays, but in some distros, sh redirects to a more minimalist shell like dash, or ash.

But when writing a plain shellscript - you have to be careful to avoid any shell-specific extensions to the shellscript language - you have to write your shellscript as generically as possible. That will allow you to write generic shellscripts that can be sent to different systems and can run on any compatible shell. And on Linux there are loads of different shells available.


Alternatively, you could target a particular shell/interpreter.
Most Linux distributions use Bash as the default shell. A few use other shells as the default, but bash is usually installed alongside the default shell too.

So I'd recommend learning and targetting bash. Bash has added some really useful extensions to their inplementation of shellscript. ksh and zsh are two other popular shells - there are a few others.
Each of those support generic shellscripting, but also have their own additional extensions and features.
But bash is probably your best bet when starting out. It's the most commonly used and it's just everywhere!
In order to write a shellscript specifically for bash, you'd use one of the following shebang lines:

#!/bin/bash

Or

#!/usr/bin/env bash

If you were writing a script for zsh, or ksh, or some other shell - then you'd swap out bash in the above for the path to whatever shell you want to use to run your script.

IMPORTANT:
The shebang line MUST be the very first line in your script. Without a shebang, the interpreter won't know which program to run in order to run/interpret the script.

Let's say we open a text editor and create a "Hello world!" script

#!/usr/bin/env bash
echo "Hello world!"

Open up a text editor - either in a terminal, or in the GUI and enter the above two lines of code.
After saving the scirpt as "Hello" at the root of our home directory, we open a terminal to our home directory (if we aren't already in a terminal) and give the script executable permissions:

chmod +x ./Hello

Now we have an executable shellscript in our home directory called Hello.
To run it, we would typically use:

./Hello

Because we have the shebang line - the shell will know to run our script using bash.
When running one of the scripts in our home directory, we need to prefix our script name with ./ because when we enter any command our shell (bash, or zsh, etc) looks in directories specified in $PATH.
Our home directories are NOT listed in $PATH.
So if we tried running our script using:

Hello

We'd get an error saying something like:

bash: Hello: command not found

This is because our script was not found in any of the directories specified in the shells $PATH environment variable.
So in order to run our script, we need to specify the path to our script.
So, assuming we're in the terminal and we're in the root of our home directory (which is where we saved the Hello script), we need to specify the current directory as the path to the script.
So we run our script using:

./Hello

Which tells the shell to run the file called Hello in the current directory.

If we decide to move into our Downloads directory:

cd Downloads

So now we're at /home/username/Downloads and our script is at /home/username/Hello.
If we want to run our script from the current location, we would either have to use:

../Hello

Where ../ means "the previous directory" in the file-system hierarchy.
This is the relative path to our script - relative to the current directory.
Alternatively, we could run it using:

/home/username/Hello

Where username is your actual username.
This is the absolute path to our script, because it specifies the path to our script from the root / of the file-system.
Or:

$HOME/Hello

Where $HOME is the environment variable that holds the absolute path to our home directory (/home/username/).
Or:

~/Hello

Where ~/ is a shortcut for /home/yourusername, or $HOME.

Who knew there were so many ways to run a script?!

With your scripts, you can go one step further and put them somewhere in $PATH.
So if you wrote a script that is REALLY useful and you want it to be available system wide, you could consider copying it as root to /usr/local/bin/. Then you'd be able to run your script just by invoking its name in the terminal without having to specify a path to it.

Or if your script is something that you want to keep to yourself and you want to just be able to run your scripts from anywhere on your system without having to specify the full path to it each time - you could set up a personal bin directory in your /home directory. I won't go into any detail on that here, that's well beyond the scope of this particular reply. But I have posted instructions on how to set up a personal bin directory in other posts here. I highly recommend it. Once you've set up a personal bin directory, you can copy any scripts or executables that you've built into it and can run them as if they are any other terminal command.


Additional notes on the shebang line:
If we didn't have a shebang line, the shell would not know which interpreter to use and would just assume that the script contained commands for the running shell - which will be bash a lot of the time, so no harm there.

However, you're not just limited to shellscripts. You can use a shebang line as the first line in ANY script, in ANY scripting language you like.
So for Python3, you'd specify the path to python3 in the shebang.
For Perl, or Lua, PHP or even more obscure scripting languages like lolcat - you can use a shebang to specify the path to the correct interpreter for those languages too.

Bearing this in mind - if our "Hello" script was a Python3 script and we didn't use a shebang to specify that python3 should be used, the shell would attempt to run the python3 script as a series of shell commands and you'd potentially end up getting a bunch of errors output to the screen.

So again - that is why we always include a shebang line as the first line of ANY script.

The main advantage of using a shebang is that you don't need to use a file-extension at the end of your file-name to differentiate the type of script. That way you can make your scripts look like any other installed command.

So instead of having to call our script Hello.sh - we can simply call the script Hello.
Running ./Hello just feels a lot nicer than having to type ./Hello.sh, it just makes your scripts seem more like any other installed command.

If you take a look at the files in your /usr/bin/ directory - you'd be surprised at the different types of files in there. Many will no doubt be compiled, executable ELF binaries built using C/C++, Rust, or some other compiled programming language. Some will be symbolic links to other files (symbolic links are like shortcuts in Windows). But a good number of them will be scripts - shellscripts, Python scripts, Perl scripts, Lua scripts, ruby scripts etc etc.
Almost none of the script-based commands in /usr/bin/ will have any identifying file extensions like .py, or .pl, etc. And this is purely because we use shebangs.

Without a shebang line, the only other way to run a script would be to run the interpreter in the shell and pass it the name of the script.
e.g.

bash  /path/to/MyShellscript

or

python3 /path/to/MyPython3Script

Again - not as convenient as having a shebang in the script and having our script in a personal bin direcotry, or in a system direcotry like /usr/local/bin/ and being able to just enter:

MyShellscript

or

MyPythonScript

Finishing up (finally!)
I have a personal bin directory, I use shebangs in all of my scripts and I don't typically use file extensions for ANY of my scripts.

When it comes to learning shellscripting, there are literally resources all over the internet!
All a shellscript is, is pretty much a bunch of shell commands strung together using a bit of shellscript syntax.

On Linux, the terminal is insanely powerful. The shellscripting language itself is relatively simple, but it is so versatile and expressive. You can string a bunch of different commands together and pipe, or redirect the output from one command to the input of another. You are only limited by your imagination.

A small part of shellscripting is learning the actual shellscripting syntax. But the largest part is learning to combine the vast multitude of existing programs/scripts and commands that we have available to us in our scripts.

As with anything, it takes a while to build up a working vocabulary of terminal commands. And very often there is more than one way to get something done. So using the terminal regularly and exploring and getting familiar with the commands available to us is a good idea. Exploring the man and info pages, to discover what options are available to us for any given command is also worthwhile. Sometimes the man pages can be a bit of a heavy read. But it's often worth it, because you can find some insanely useful bits of obscure functionality in some of the commands.

Start small and gradually work your way up to bigger things. Again, there are resources all over the internet for learning bash/shellscripting and Linux terminal commands.

 

[DxHum]

The equivalent to a DOS batch file would be a shellscript.
To create a shellscript, you can just use any text editor.
Whichever editor you use is completely up to you.

You could use editors like nano, vim, neovim, emacs, spacemacs, joe etc. in the terminal, or you could use a GUI based text editor - Kate, leafpad, gedit, gvim, Caja, the GUI version of emacs/spacemacs, neovim etc etc..

Whatever Linux distro you have installed, you will almost certainly have nano and vi pre-installed in the terminal. vi is just vim-minimal with the 'compatible' option turned on, which makes vim behave exactly the same as the classic vi. vi/vim aren't for everybody though. Personally, I love it.
But nano is probably the simplest terminal based text editor. So you might want to try nano.

Alternatively, your desktop environment should also have at least one GUI based text editor pre-installed. But exactly which one you have will depend entirely on the Desktop you have installed.

You could give your shellscripts a .sh extension, in order to identify them as shellscripts, but that is entirely optional. In Linux, we generally use a shebang line as the first line of our scripts, which tells the shell which interpreter to use to run a script.

So for a generic shellscript, we'd start our shellscript with a shebang like:

#!/bin/sh

or

#!/usr/bin/env sh

That tells the shell to use whatever the default minimal shell is. Very often sh just redirects to bash nowadays, but in some distros, sh redirects to a more minimalist shell like dash, or ash.

But when writing a plain shellscript - you have to be careful to avoid any shell-specific extensions to the shellscript language - you have to write your shellscript as generically as possible. That will allow you to write generic shellscripts that can be sent to different systems and can run on any compatible shell. And on Linux there are loads of different shells available.


Alternatively, you could target a particular shell/interpreter.
Most Linux distributions use Bash as the default shell. A few use other shells as the default, but bash is usually installed alongside the default shell too.

So I'd recommend learning and targetting bash. Bash has added some really useful extensions to their inplementation of shellscript. ksh and zsh are two other popular shells - there are a few others.
Each of those support generic shellscripting, but also have their own additional extensions and features.
But bash is probably your best bet when starting out. It's the most commonly used and it's just everywhere!
In order to write a shellscript specifically for bash, you'd use one of the following shebang lines:

#!/bin/bash

Or

#!/usr/bin/env bash

If you were writing a script for zsh, or ksh, or some other shell - then you'd swap out bash in the above for the path to whatever shell you want to use to run your script.

IMPORTANT:
The shebang line MUST be the very first line in your script. Without a shebang, the interpreter won't know which program to run in order to run/interpret the script.

Let's say we open a text editor and create a "Hello world!" script

#!/usr/bin/env bash
echo "Hello world!"

Open up a text editor - either in a terminal, or in the GUI and enter the above two lines of code.
After saving the scirpt as "Hello" at the root of our home directory, we open a terminal to our home directory (if we aren't already in a terminal) and give the script executable permissions:

chmod +x ./Hello

Now we have an executable shellscript in our home directory called Hello.
To run it, we would typically use:

./Hello

Because we have the shebang line - the shell will know to run our script using bash.
When running one of the scripts in our home directory, we need to prefix our script name with ./ because when we enter any command our shell (bash, or zsh, etc) looks in directories specified in $PATH.
Our home directories are NOT listed in $PATH.
So if we tried running our script using:

Hello

We'd get an error saying something like:

This is because our script was not found in any of the directories specified in the shells $PATH environment variable.
So in order to run our script, we need to specify the path to our script.
So, assuming we're in the terminal and we're in the root of our home directory (which is where we saved the Hello script), we need to specify the current directory as the path to the script.
So we run our script using:

./Hello

Which tells the shell to run the file called Hello in the current directory.

If we decide to move into our Downloads directory:

cd Downloads

So now we're at /home/username/Downloads and our script is at /home/username/Hello.
If we want to run our script from the current location, we would either have to use:

../Hello

Where ../ means "the previous directory" in the file-system hierarchy.
This is the relative path to our script - relative to the current directory.
Alternatively, we could run it using:

/home/username/Hello

Where username is your actual username.
This is the absolute path to our script, because it specifies the path to our script from the root / of the file-system.
Or:

$HOME/Hello

Where $HOME is the environment variable that holds the absolute path to our home directory (/home/username/).
Or:

~/Hello

Where ~/ is a shortcut for /home/yourusername, or $HOME.

Who knew there were so many ways to run a script?!

With your scripts, you can go one step further and put them somewhere in $PATH.
So if you wrote a script that is REALLY useful and you want it to be available system wide, you could consider copying it as root to /usr/local/bin/. Then you'd be able to run your script just by invoking its name in the terminal without having to specify a path to it.

Or if your script is something that you want to keep to yourself and you want to just be able to run your scripts from anywhere on your system without having to specify the full path to it each time - you could set up a personal bin directory in your /home directory. I won't go into any detail on that here, that's well beyond the scope of this particular reply. But I have posted instructions on how to set up a personal bin directory in other posts here. I highly recommend it. Once you've set up a personal bin directory, you can copy any scripts or executables that you've built into it and can run them as if they are any other terminal command.


Additional notes on the shebang line:
If we didn't have a shebang line, the shell would not know which interpreter to use and would just assume that the script contained commands for the running shell - which will be bash a lot of the time, so no harm there.

However, you're not just limited to shellscripts. You can use a shebang line as the first line in ANY script, in ANY scripting language you like.
So for Python3, you'd specify the path to python3 in the shebang.
For Perl, or Lua, PHP or even more obscure scripting languages like lolcat - you can use a shebang to specify the path to the correct interpreter for those languages too.

Bearing this in mind - if our "Hello" script was a Python3 script and we didn't use a shebang to specify that python3 should be used, the shell would attempt to run the python3 script as a series of shell commands and you'd potentially end up getting a bunch of errors output to the screen.

So again - that is why we always include a shebang line as the first line of ANY script.

The main advantage of using a shebang is that you don't need to use a file-extension at the end of your file-name to differentiate the type of script. That way you can make your scripts look like any other installed command.

So instead of having to call our script Hello.sh - we can simply call the script Hello.
Running ./Hello just feels a lot nicer than having to type ./Hello.sh, it just makes your scripts seem more like any other installed command.

If you take a look at the files in your /usr/bin/ directory - you'd be surprised at the different types of files in there. Many will no doubt be compiled, executable ELF binaries built using C/C++, Rust, or some other compiled programming language. Some will be symbolic links to other files (symbolic links are like shortcuts in Windows). But a good number of them will be scripts - shellscripts, Python scripts, Perl scripts, Lua scripts, ruby scripts etc etc.
Almost none of the script-based commands in /usr/bin/ will have any identifying file extensions like .py, or .pl, etc. And this is purely because we use shebangs.

Without a shebang line, the only other way to run a script would be to run the interpreter in the shell and pass it the name of the script.
e.g.

bash  /path/to/MyShellscript

or

python3 /path/to/MyPython3Script

Again - not as convenient as having a shebang in the script and having our script in a personal bin direcotry, or in a system direcotry like /usr/local/bin/ and being able to just enter:

MyShellscript

or

MyPythonScript

Finishing up (finally!)
I have a personal bin directory, I use shebangs in all of my scripts and I don't typically use file extensions for ANY of my scripts.

When it comes to learning shellscripting, there are literally resources all over the internet!
All a shellscript is, is pretty much a bunch of shell commands strung together using a bit of shellscript syntax.

On Linux, the terminal is insanely powerful. The shellscripting language itself is relatively simple, but it is so versatile and expressive. You can string a bunch of different commands together and pipe, or redirect the output from one command to the input of another. You are only limited by your imagination.

A small part of shellscripting is learning the actual shellscripting syntax. But the largest part is learning to combine the vast multitude of existing programs/scripts and commands that we have available to us in our scripts.

As with anything, it takes a while to build up a working vocabulary of terminal commands. And very often there is more than one way to get something done. So using the terminal regularly and exploring and getting familiar with the commands available to us is a good idea. Exploring the man and info pages, to discover what options are available to us for any given command is also worthwhile. Sometimes the man pages can be a bit of a heavy read. But it's often worth it, because you can find some insanely useful bits of obscure functionality in some of the commands.

Start small and gradually work your way up to bigger things. Again, there are resources all over the internet for learning bash/shellscripting and Linux terminal commands.

Thank you for the detailed reply. You've given me a lot to research and work with.

I did search for (and found) a tutorial on bash, but it wasn't nearly as complete and extensive as your reply here.

I love the idea of working in terminal and it is why I've begun learning Linux; I miss the days of issuing commands directly to the system from the DOS prompt.

Please allow me some time to explore the things you've mentioned here. I am certain more questions will follow.

 

[Diputs]

Is the equivalent a script file? If so, what do we use to write it?

Windows and Linux/Unix are very different when it comes to scripts.
I write both a lot, and that enables to see the differences, but also the similarities.

In Linux/Unix a script is written as a type of Shell (which should or could be listed in line number 1 of the script).
And, there are many shells. But, there's also one which is considered to be the master, according to me at least, and that is Bash. This is the Bourne Again SHell. In Linux, lots of naming and references have some cheeky naming to it.

Windows is 100% corporate code, that is quite obvious. All humor is removed in professional manner.
The Windows scripts can be referred to as DOS scripts since they still share a lot with ancient DOS versions, but, to be clear, there is no DOS in modern Windows ! There is just this evolution of DOS infrastructure, and the CMD box looks like DOS, to this day. In addition there is also Powershell which is a much more complex system to allow scripting and which looks extremely odd to me, I see no DOS or Bash in this.

But, script in Linux : choose a Shell, and write some code. Script names don't even need a certain extension, or an extension at all even, but in general people use .SH for Bash shells (but not only for Bash shells). Important (should be) the first line which tells what Shell it is, and then an Execute permission on the file and go !

Windows scripts, or batch files, can only be .BAT or .CMD and there is no difference other than the order in %PATHEXT%
Older Windows can't handle CMD but I think these would be very old.

 

[MikeRocor]

In my first role where I wrote Unix scripts for administrative purposes, my mentor advised me to always write scripts for the bourne shell ( #!/bin.sh ) because they will work on pretty much any unix / linux system. Since then, I've lightened up a little in that regard such that if a scripting project truly -requires- bash features that aren't available in sh ( or if such would provide a benefit that outweighs the possibility of not having bash or the inconvenience of having to install it ) then, by all means, use bash.

While it is trivial to load bash on my system, I hardly ever do so and my scripts are written to run generically on sh which, on my system, is really busybox ash. Many, if not most, linux distros come with bash by default these days, so there's certainly nothing -wrong- with scripting for bash.

As for naming, my personal habit is to not use any file name extension for scripts. Buy if you must use one, you should make it descriptive and accurate. For instance, a script named foo.sh but with a shebang that references bash instead of sh will work if bash is present. But the name implies that it will run even if only sh is present but in that circumstance the script will generate an error indicating "sh: foo.sh: not found" when foo.sh is clearly present. The error message is actually the current shell indicating that the interpreter for foo.sh was not found but the message is unclear enough that only "an experienced script programmer" (one who has already pulled his hair out) will understand that without some wild goose chasing. While naming a sh script "foo.sh" and a bash script "foo.bash" would make sense, I think it would also be a bit cumbersome and, IMO, it would be better to just call the script "foo" and then check the shebang if you need to debug.

---

DOS batch language was probably designed specifically as a torture device. Writing non-trivial batch programs is possible - I've done it - but it aint pretty. It is much improved in modern Windows... Too bad I've pretty much abandoned Windows. Powershell is a crime against nature... So glad I've pretty much abandoned Windows.

 

[Diputs]

Windows/CMD users acknowledged the limitation of scripting in this environment, and when they looked for expansion, the obvious direction they looked was towards something better ... and that would be Linux. So, many Linux tools got ported to Windows/CMD in order to enjoy better features on Windows as well. Stuff like GREP, and AWK, and whatnot, are just .EXE's and .DLL's then. A big name here is CygWin ( https://cygwin.com ) but Microsoft itself doesn't care because they hope Powershell will deliver what it should. CMD with CygWin is actually powerful, but keep it quiet.

It's correct that code ends up to be as beautiful as the syntax and functions allow it to be.
CMD is pretty simple indeed. Bash (and Linux) scripting is much better in that regard.

 

[dos2unix]

DOS was Microsoft before Windows. I remember the Atari, Apple II, and Commodore 64 days.
All we have was command line. I remember when the Macintosh and Amiga first came out, everyone
I know with a Micro$oft computer said... that windows thing is just a fad. That mouse thing will never catch on.

The earliest versions of a word processor I can remember, were closer to vi, than to what we call "Word" today.

DOS came out for Microsoft is 1981, Windows didn't appear until 1985, and even then, it was a cruel joke.
Windows wasn't really very accepted until Windows 3.1, released in 1992, eleven years after the first Microsoft DOS.

To put this in perspective, Apple had the Macintosh in 1984, over a year before Windows was released.
The Commodore Amiga was first released in 1985 also. It was almost 7 years later before Windows became
popular with the release of Windows 3.1.

Most computers in those days didn't support broadband. You had a serial port connected to a modem.
All OS's didn't support networking in those days. You had to buy network adapters and install them in
your PCI slots. Wi-Fi didn't exist yet.

The Apple Lisa was the computer I remember using with a mouse.
Apple first had consumer computers in 1976, about five years before the first Windows PC.

AT&T/Bell UNIX first appeared in 1971. This is what Linux is loosely based on. But Linux didn't appear until
1992. The first major distro was Slackware. Although if you knew enough, you could piece together your
own versions, as "distro's" with installers, and package managers weren't really a thing yet.

 

[MikeRocor]

Dang it dos2unix, You just had to use the "A" word, didn't you!?

In the course of moving, I've run across my old Amiga 1000. Dunno if I still have a monitor that will work with it (probly not) nor if I have any working diskettes for it (sadly, also probly not). Definitely not the hard disk, though I have some junk scsi drives that might work If I ever get to that point. It's gonna be a long time before I have time to even check it out, though.

 

[bob466]

Didn't Gates say...DOS is dead.

 

[Diputs]

Didn't Gates say...DOS is dead. View attachment 20409

How is it when the current command line interface obviously is an improved evolution of it ?

As long as PowerShell isn't killing that one, it'll remain alive.
DOS is just a name, renaming it doesn't kill it.

What I most hate about DOS is gone, which is that base and extended 640K memory usage thing ...
But the COPY command is still like it was created in 1986.

 

[Brickwizard]

What I most hate about DOS is gone,

How can it be gone, how can it be dead, DOS was not the preserve of one company, there were many variations, but they were all Dos, DISK OPERATING SYSTEM's [or operating systems run via non-volatile memory as we call it now]. First it was running the system via 5 " floppy, then 31/2 cassette disc [some used compact cassette and players], others used CD then DVD before it became a full on board OS with the advent of the plate spinner hard-drive, now we have NVMe and SSD but the principle is still the same, it is a means of running a computer using non-volatile storage, take any OS Take out all the bells and whistles stripping it back to the bare minimum and you have DOS. a basic Disc Operating System