I'm trying to learn how to create a makefile and I faced couple of issues related to commands which I should use.
ls is something i know to list directories.
rm is something I know to remove file or directory and some other.
Then I learnt that Unix-cmd is different from command prompt in windows and also from powershell.
I'm using Windows 11 to create a make file. and I found alternate commands for the above like
dir /a:b, instead of ls
erase instead of rm.
What is the difference btw these shells and where to find them?
Makefile:
print: $(wildcard *.c)
ls -la $?
Error I got:
ls
'ls' is not recognized as an internal or external command,
operable program or batch file
I want to know a little more info about them.
Also what makes are available something which gives some overview. Names are sufficient.
Related
I am trying to move all text files with a specific name in them from one directory to another using bash on a windows machine in cygwin. The code is below and but I am not sure how to reference a windows path in bash. Thank you :).
for i in "C:\Users\cmccabe\Desktop\annovar"; do
mv $i"\"*multianno.txt "C:\Users\cmccabe\Desktop\all""\"basename $i`multianno.txt
done
mv: cannot stat ‘C:\\Users\\cmccabe\\Desktop\\annovar\\*multianno.txt’: No such file or directory
You should use cygpath, which is a cygwin utility for converting windows to/from cygwin paths.
Without additional arguments it will transform a given windows path to its cygwin equivalent, which is what you want :
mv $(cygpath "windows_src") $(cygpath "windows_dst")
I wasn't sure it would work with paths containing jokers, but it looks like it does :
$ cygpath "C:\path\*a*"
/cygdrive/c/path/*a*
I have a couple of batch files I want to use regularly, so I decided I would drop them as symlinks into a binaries folder in my path. The idea being that I would use them like I would any other command, without having to change directories. E.g.
> odbimport -u User -f filename
where odbimport is my symlink to the batch file odbimport.bat.
The process I used to make the symlinks is as follows:
C:\Users\user>mklink C:\utils\odbimport C:\util-files\odbimport.bat
symbolic link created for C:\utils\odbimport <<===>> C:\util-files\odbimport.bat
C:\Users\user>path
Path=C:\....;C:\utils\
C:\Users\user>where odbimport
C:\utils\odbimport
From what I've seen, it looks like I've made the symlink, and the path knows where to find it.
However, after I've made my symlink and attempt to execute, I get:
C:\Users\user> odbimport -u me -f somefile
'odbimport' is not recognized as an internal or external command,
operable program or batch file. "
I've been looking for an answer to this with no success. Everything I find seems to deal more with how to create working symlinks than addressing my issue. The closest thing I found was this. This is essentially my question, except kinda backwards because I don't really want to run the symlinks from Windows Explorer. I have also tried adding .LNK to my PATHEXT variable as in this question.
Add .bat extension to the symlink you create because on Windows .bat extension is necessary to tell the system it's actually an executable batch file. You will still be able to run the file by typing its name only.
mklink C:\utils\odbimport.bat C:\util-files\odbimport.bat
NTSF hardlinks can be used when source and target are on the same volume, the advantage is that such clones may be executed from Windows Explorer unlike symlinks:
mklink /h C:\utils\odbimport.bat C:\util-files\odbimport.bat
fsutil hardlink create C:\utils\odbimport.bat C:\util-files\odbimport.bat
Not sure if anyone else has gotten this to work, but I'm having no end of trouble even with the following simple line in my Makefile running mingw32-make:
mklink Mk Makefile
The following created the link, but mingw32-make puked and threw error 255 thereafter:
$(shell cmd /c 'mklink Mk Makefile')
Nothing else is problematic, and I have a relatively complex makefile. Only mklink is doing this. (Apparently msys has it's own problems with ln so going down that path appears pointless.)
The following works for me, (on Win7 Home Premium, in VirtualBox),
provided I invoke it in a shell running with administrator privilege:
$ cat makefile.tst
all:
cmd /c "mklink mk makefile.tst"
#echo "Success!"
$ make -f makefile.tst
cmd /c "mklink mk makefile.tst"
symbolic link created for mk <<===>> makefile.tst
Success!
$ rm mk
$ mingw32-make -f makefile.tst
cmd /c "mklink mk makefile.tst"
symbolic link created for mk <<===>> makefile.tst
Success!
My shell, in this case is MSYS sh.exe, invoked via msys.bat from cmd.exe with UAC escalation to administrator privilege. This is so that I can show that the mklink command works both in MSYS' own make.exe, and in mingw32-make.exe; (of course, the mingw32-make.exe example also works directly from the elevated cmd.exe shell itself).
I suspect that attempting to use mklink directly within the makefile, without the cmd /c preamble, may not work because mklink is a cmd.exe built-in, which GNU make may not know to run this way ... it reports a CreateProcess failure, because the specified file cannot be found, when I try it.
Your use of make's $(shell ...) construct would not work, because that causes make to invoke the command in the wrong phase of operation ... when parsing the makefile itself, and constructing its dependency graph, rather than as a command to run when the containing rule is invoked, where it will now attempt to execute the output from the $(shell ...) command as a command in its own right; this is clearly not what you want!
Just to clarify the position with regard to MSYS' own ln command: it does work as well as can be expected, within the limitations of the versions of Windows on which it was originally implemented. In particular:
$ ln fileA fileB
creates a file-to-file hard link, on file systems such as NTFS, which support such links, and falls back to creating a copy on file systems such as FAT, which don't. Also:
$ ln dirA dirB
fails, as it should; hard linked directories are a recipe for disaster, and are not allowed, (just as they are forbidden on unix platforms). However:
$ ln -s fileA refB
will not create a symbolic link, (because no version of Windows supported them at the time when MSYS was developed, and no one has stepped forward to implement the capability, since they have become available ... although, their implementation still seems flaky, on Vista and Win7 anyway); rather, this command falls back to creating a hard link if possible, or a file copy otherwise. Similarly:
$ ln -s dirA refB
will not create a symbolic directory link, and in this case, there is no fall back; it simply and unconditionally fails! (It might be argued that a deep copy of the directory could be a suitable fall back action, but it isn't implemented so; instead, the lndir command is provided, to facilitate this).
I installed Strawberry Perl to run the rouge program in Windows. But when I want to run my program, I receive an error message that you can see on the image:
The system can't find the path specified.
My code is attempting to run "ROUGE-1.5.5.pl" but i think the system can't find this file. So I think maybe I don't initialize the path correctly?
I change my code to :
#!/usr/bin/perl
use Cwd;
$curdir=getcwd;
$ROUGE="..\ROUGE-1.5.5.pl";
chdir("sample-test");
$cmd="$ROUGE -e ..\data -c 95 -2 -1 -U -r 1000 -n 4 -w 1.2 -a DUC2002-ROUGE.in.26.spl.xml > ..\sample-output\output.out";
print $cmd,"\n";
system($cmd);
chdir($curdir);
and i receive this error:
Missing braces on \o{} at C:\runROUGE-test.pl line 7, near "$ROUGE" Execution of C:\runROUGE-test.pl aborted due to compilation errors.
As per the screen shot, you are attempting to run \ROUGE-1.5.5.pl where you probably want it without the spurious backslash (or with ..\ROUGE-1.5.5.pl if the parent directory is not on your PATH).
Similarly, you probably want the output in sample-output\output.out, or even just output.out, not \sample-output\output.out unless you specifically have a folder C:\sample-output for this purpose.
The backslash is significant; it is the absolute path to the root (of the current drive, on Windows). ..\ is the relative path to the parent folder.
Why are you writing a Perl script to run a Perl script, though? Either a simple batch file, or copy/pasting the command directly at the DOS prompt would seem like a less roundabout solution.
The problem is that when you are outputting the contents of the program to the file output.out in folder sample-output, the sample-output folder does not exist.
Command Prompt will not create the folders for you, only the files. Try creating a directory first called "sample-output" (In your drive root) such that the path resolves to something like C:\sample-output and run it again.
If the same problem results, try using an absolute path such as C:\sample-output\output.out instead.
On the Windows command line and cygwin bash I can execute the following without problems:
cvs login
cvs -Q log -N -rVersion_01_00
A ruby script in the same directory contains the following:
`cvs login`;
`cvs -Q log -N -rVersion_01_00`;
When I execute the ruby script on the Windows command line I get the following error:
cvs log: warning: failed to open /cygdrive/c/Documents and Settings/za100744/.cvspass for reading: No such file or directory
If I run the script in a cygwin bash shell I get the same output I would as when I type in the commands manually.
I have no idea as to what is going wrong. The path generated by the Ruby script is wrong since it is a cygwin path but it works correctly directly on the command line. I use cvs that came as part of cygwin:
which cvs
cvs is an external : C:\cygwin\bin\cvs.exe
Ruby is the one-click installer version:
which ruby
/cygdrive/c/Ruby/bin/ruby
It seems like cvs under Ruby can not resolve /cygdrive/c to c: but works OK from the cmdline.
Perl gives me exactly the same problem.
my $str = "cvs -Q log -N -r$cvs_tag|";
open(CVS_STATUS, $str) or die "\n##ERROR##";
It looks like either CVS can't create the file, or your path is wrong. Does the file .cvspass exist? If not, this page suggests you try creating an empty .cvspass file and then run your command. e.g. do
touch ~/.cvspass
If this doesn't help, then the problem is probably path related. There are a few possibilities; $HOME not set correctly, your home dir not matching what's in \etc\passwd, etc. See this tutorial for some troubleshooting steps that should help pin down the problem.
Using a windows native compiled CVS solves the problem. It is not ideal since I have to send a cvs executable with the script for users that has cygwin CVS but its better than nothing.
We had several problems with unix-, mixed- and windows-style paths in cygwin based perl scripts and built-in tools such as rsync. E.g. rsync can't handle wind-style paths. Use the tool "cygpath.exe" to adjust them correctly. Maybe it's the cause.