I’m writing a LaTeX package which needs to use \write18. Some of the shell commands I issue are system-specific (e.g. rm vs. del). Is there a way to determine what system I’m running on?
It would be enough to disambiguate between Windows and other (Unix-like) systems.
Take a look at the LaTeX ifplatform package. There was a lot of discussion about reliable methods across a range of platforms, and the current release works very well.
Not very good but it works for me
\newread\checkf
\immediate\openin\checkf = C:/WINDOWS/win.ini
\ifeof\checkf not windows \else windows\fi
\closein\checkf
If you can mark your OS with a file you can do
\IfFileExists{/etc/motd}{unix code here}{windows code here}
There's nothing special about the path /etc/motd; it's just likely to be found on a Unix system and unlikely on a Windows system. If you want to be dead certain, you should create a file specifically to mark the system in whatever way you want to identify it.
A friend of mine had the following idea which I’m now using. I’ve only tested it on Windows XP and OS X where it works fine. A bit flimsy on testing, admittedly, but in principle it should work fine almost anywhere else.
\newif\ifwindows
\immediate\write18{echo $SHELL > \jobname.os}
\newread\#whichos
\immediate\openin\#whichos\jobname.os
\read\#whichos to \#whichosshell
\ifthenelse{\equal{\#whichosshell}{$SHELL }}
{\windowstrue}
{\windowsfalse}
\closein\#whichos
\ifwindows
\typeout{System detected: Windows}
\newcommand\DeleteFile[1]{\immediate\write18{del #1}}
\else
\typeout{System detected: Unix-like}
\newcommand\DeleteFile[1]{\immediate\write18{rm #1}}
\fi
% Cleanup.
\DeleteFile{\jobname.os}
The key here is that Windows won’t expand the $SHELL environment variable (any other variable would have done, really) so it will write the string $SHELL to the file literally.
Related
I'm running a bash script in the Embedded Command Line that comes with Quartus II. The bash script was sent to me from someone using linux and I was able to get most of the script to work(removing sudo, changing path, etc.). The only two commands that are still giving me errors are mkfs.ext3 and mkfs.vfat. Are these tucked away somewhere in cygwin that I need to add a path or is there another workaround? I've read some people use mkdofsf but cygwin doesn't appear to have that either.
UPDATE:
Tried using /sbin/mkfs - t vfat and /sbin/mkfs -t ext3 but this left me with a similiar error where mkfs.vfat and mkfs.ext3 were not found.
UPDATE 2: Installed e2fsprogs to solve the error with mkfs.ext3 but this doesn't solve the vfat formatting issue.
These are part of the package e2fsprogs which is available in Cygwin. I've never tried these commands, assuming that access to the raw devices would be blocked by Windows. But I see that cfdisk seems to work. It at least starts up, anyway. So, maybe it is doable.
If they don't work on raw devices, if your scripts are creating file systems on a file or can be modified to do that, that should probably work.
Anyway, e2fsprogs is what you need, but be careful here. Whenever you start making or editing file systems, you have the opportunity to really screw up your system. Just be attentive to what the script is doing, and don't blindly go forward.
I use GNU Emacs on Windows with git-bash for unix tools like locate, grep and find. The git-bash tools spit out paths in the following form:
/c/path/to/file/file.txt
Emacs needs for functions like find-file, find-file-at-point or (with the helm-package) the function helm-find-file its paths in the form
c:/path/to/file/file.txt
I wrote a converter-function which converts the former into the latter and I hooked it via defadvice in expand-file-name. This works reasonable well (e.g. in my initial use case to make helm-locate cooperate with the git-bash locate).
However in some cases it does not work, like in interactive use of find-file-at-point. So my question is what is a more universal place to hook this converter in to make even interactive calls work properly?
jenesaisquoi's comment brought me to cygwin-mount.el. I tried it with gitbash - and it magically works!
The reason is that gitbash provides a similar mount command as cygwin does and gitbash's paths are cygwin paths as well.
Just make sure the gitbash binaries are in emacs' PATH environment variable.
I understand that console applications using git bash invoke sh.exe but I wonder how they continue to use sh.
I see on console apps often you do a sh.exe --login. I would guess this creates a session somewhere and I would presume that the console application would execute commands against it somehow?
Essentially I switched from UNIX to Windows. I have tried a lot of console apps (best being console2 and just git-bash) but they still do not work for me well.
Ia m annoyed enough that I fancy trying to programming a simple shell in Java. (I am a Java developer by trade.)
Any help would be great thanks to understand this, looking but searchs with console or git-bash in google generate so much random noise.
If you are using one of the various Unix shells ported to Windows, you should be aware that most of these shells use some heuristic to make Windows look like Unix, either to build a compatibility layout or for user convenience.
For instance, the git command is probably stored in a git.exe file but your shell scripts imported from your Unix workstation all say git so the shell will lookup git.exe if it does not find git.
Nobe of these heuristics works perfectly, so you have to expect regular inconsistencies and disagreements, especially if your are mixing several Unix ports together.
As for the meaning of --login, it is synonymous to -l and its main effect is to decide which initialization files are read by bash on startup`
-l Make bash act as if it had been invoked as a login shell (see
INVOCATION below).
Is there a way that we can write automation scripts in bash syntax and run it on Windows host (We can call the executable file .exe of Windows). The Windows batch syntax looks quite complex :D
Any suggestions are appreciated.
You can use cygwin or mingw sys for this.
They are both just BASH implementation available on WinXX (actually they are much more, but you need now only bash).
But there are some differences:
cygwin uses its own file system hierarchy, with Win drives mapped to a part. subdirs. All related to file names is more unix-style. There are some problems with passing pathnames to Windows programs.
MinGW is more Windows friendly, file paths are like in Windows, less problems with Windows native programs.
You should try yourself and choose what you need.
You could install cygwin and run bash.
You can get a win32 port of bash. Cygwin is enormous, but native windows bash and a few utilities can be had for a much smaller footprint.
Start with UnxUtils, which includes a sh based on zsh (it's quite slow, though).
If that's not enough you can get a win32 bash from some places, though most are older versions.
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703