Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

When I am trying to execute a file(name.sh) in the command line by the command ./name.sh , I am getting the error that:

"." is not recognized as an internal or external command, operable or batch file

please help me execute the .sh file

share|improve this question

migrated from stackoverflow.com Mar 15 '10 at 8:36

This question came from our site for professional and enthusiast programmers.

add comment

10 Answers

You're on Windows CMD.EXE (from the error message). It uses a different syntax to execute commands. You'll need to use sh name.sh, assuming that you've got Cygwin or similar installed.

To clarify, Windows does not have a built-in utility to support .sh files. To run such, you'll need to install a third-party tool such as Cygwin.

share|improve this answer
13  
Perhaps to add a clarification. Windows does not have a built in utility to support .sh files and you need to install a third party tool such as Cygwin to run .sh files. –  BBlake Mar 15 '10 at 12:52
add comment

Windows doesn't natively run .sh. shell scripts. Have you installed something like CygWin, or are you just trying to run it natively in cmd.exe?

share|improve this answer
add comment

You are trying to run a Linux command at the Windows Command Prompt.

On Linux the forward slash is a path separater. On Windows the backslash is a path separator and the forward slash generally indicates an argument.

Therefore, Windows thinks you are trying to run a command called "." and parsing it the argument "/name.sh". The correct convention would be ".\name.sh". Additionally Windows will automatically search the current directory for your command so you could just type "name.sh".

The next problem you will face is that Windows does not know what a sh script is, again this is a Linux thing. You could solve this by installing Cygwin if you really want or need to run a sh script.

However, judging by one of your previous comments you could just as well rename the script to name.bat and delete the "#!/bin/sh" line. Now you have a Batch file which Windows should understand. You can read more about batch files here.

share|improve this answer
add comment

Alternatively you could turn to the dark side and install Linux. From the prompt:

sh runide.sh

or

sudo sh runide.sh

Your program will run and you will have a better system as well.

share|improve this answer
add comment

You're trying to run your car on orange juice instead of gasoline. Windows shares similar commands stored in .bat or .cmd files with Unix/Linux/zOS Unix Subsystem/*ix shell scripts as these two families of operating systems share a common ancestor the DEC PDP-x machines.

If you want instant gratification, you will need to install an environment that provides a "sh.exe" program or "csh.exe" or "bash.exe" program (tsh.exe anyone?)

Alternatively, if you know Unix script commands, very well, and you know Windows .cmd and .bat file commands, very well, you can translate the .sh file into a .bat or .cmd file. Even so, you will often encounter more Unix-styled programs that have no equivalent under Windows--grep, sed, vi, emacs, etc. Thus, the call to install CygWin (no minimalist)--just to get the shell and Unix tools. Put it on a flash-drive, for these special occasions.

share|improve this answer
add comment

Someone said something about MS-DOS using / for commands and \ for paths. This is slightly misleading. Look at my example:

C:\myfoo\foo\>cd../.. 
C:\myfoo\foo\>cd..\..

Has no difference in effect. Yes, it is not true for all operations – the actual answer is simply No, or without Cygwin or SSHD you can't.

I only know because I stupidly spent half a day trying to figure out what if then fi and eval, exec do with -Djava.something when called.

share|improve this answer
add comment

It's possible that the problem is actually within the file name.sh -- you are trying to use the . command but it is attempting to run a kind of shell (e.g., csh, I think) in which that's not a valid command.

So: does name.sh start with the correct #!/bin/sh (if you are actually trying to run sh)?

share|improve this answer
1  
yes it does start #!/bin/sh cd D:\Raghu D: winzip32.exe -min -a -r D:\p thats the content of the file –  sushant Mar 15 '10 at 8:12
add comment

ok, there's a LOT wrong with that - drop the #!/bin/sh, and change the extention to bat, and it might work with a few more fixes. Then you can just invoke it by its filename as well.

The syntax of a unix shell script, and a windows batch file arn't too similar. cygwin, or a load of messing around with unxutils might make something that would work in both, but unless you're ABSOLUTELY sure the environment is always the same, it isn't worth the headache

share|improve this answer
    
drop the #!/bin/sh, and change the extention to bat, and it might work with a few more fixes. What?! I suspect you never tried this... On Windows, even the simpliest bash capabilities are unsupported or require lengthy syntax. –  Camilo Martin Aug 31 '12 at 14:29
    
The second paragraph covers the fact that its likely to not work, without a fair amount of work. –  Journeyman Geek Aug 31 '12 at 15:09
    
Well, you're right. –  Camilo Martin Aug 31 '12 at 15:11
add comment

If you have a Linux box in your home (or work) and plugged to the same network, and this network is safe, this might do the trick:

  1. Make a folder share on Windows (pretty easy, but make sure the network is safe from intruders).
  2. Mount it in Linux with mount //WinMachine/Share LinuxFolder (IIRC, and requires Samba).
  3. Using something like PuTTY, log in remotely to that Linux box.
  4. Run your command in the mounted folder.
share|improve this answer
add comment

I found a different and easy solution, called UnixUtil.

Download and unzip it to C: drive. Set the environment variable path to include C:\UnixUtils\usr\local\wbin.

This is important. DO NOT set path to C:\UnixUtils\bin

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.