I am writing a small shell script that launches a program in my wine directory.
My challenge is that I have installed this on multiple machines, some with 64
and some with 32 bit, some with English and some with Norwegian locals.
the name of the program files directory in $HOME/.wine/drive_c can thus change
from Program Files, Program Files (x86), programfiler etc..
The bash line I have so far is this:
(cd $HOME/.wine/drive_c/[Pp]rogram*/... ; wine ...)
However, the [Pp]rogram* line does not work, does anyone have a good suggestion?
That should work just fine, but since you will have both Program Files and Program Files (x86) on 64 bit installations this will always expand to Program Files which might be wrong in your case.
I would use the following to dynamically determine the correct path:
look_for='My Program/myprogram.exe'
for dir in "$HOME"/.wine/drive_c/[Pp]rogram*[Ff]*/; do
if [ -e "${dir}${look_for}" ]; then
cd "${dir}"
wine [...]
exit $?
fi
done
This loops over all possible "program files" directories and checks if the file/directory specified in $look_for exists underneath it. If it does, it takes the directory component of $look_for, cds into it and runs wine from there.
Related
I am starting out with F# and trying to get it to work with Sublime Text 3 with a package, https://github.com/fsharp/sublime-fsharp-package. After installing the package using Package Control, I see F# appear as an available language to use in Sublime Text's bottom bar, and syntax highlighting appears to work more or less, from what I can tell, but the build system for F# fails to appear as it should.
So, trying to fix things, I run "build.sh install" and get an error, "Cannot open assembly '.paket/paket.bootstrapper.exe': No such file or directory." I am sort of stuck. Many thanks for any help.
From the comments you've made, you appear to be a little unfamiliar with the Unix underpinnings of OS X. I'll explain those first, then I'll suggest something for you to try that may fix your problem.
Technically, files or directories whose name starts with . are not "reserved for the system" as you put it; they're hidden. Now, it's true that Finder won't allow you to create files or directories whose name starts with ., because Apple didn't want to have to field all the tech-support calls from people who didn't know about the hidden-files feature: "I named my file ... more important stuff for work and now it's gone! Help!!!" But if you're in the Terminal app, then you can easily create files or directories with . as their first letter: mkdir .foo should work. You won't see it when you do ls, but ls -a (a for "all") will show you all files, including hidden files. And you can also do cd .foo and create files inside the hidden .foo directory -- and while the .foo folder won't show up in Finder, it will be perfectly accessible in the Terminal, and to any F# programs you might write.
So when you say that you cloned https://github.com/fsprojects/Paket but it failed to include the .github and .paket directories, I think you just don't know how to see them. You can't see them in the Finder (well, you can if you jump through a couple of hoops but I don't think it's worth the effort), but you can see them with ls -a. Just open your terminal, run cd /Users/Username/Paket, and then run ls -a and I think you'll see that the .paket and .github directories were indeed created by your git clone command.
So what you should probably try is this:
Go to https://github.com/fsprojects/Paket/releases/latest
Download the paket.bootstrapper.exe and paket.exe files. Put them in /Users/Username/Downloads (or wherever the default OS X Downloads directory is if it's different -- just as long as it's somewhere where you can find them easily).
Open the Terminal app.
Go to the directory where you've unpacked the Sublime Text 3 package. I.e., in the Terminal app, run cd /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master.
Run ls -a and see if there's a .paket directory.
If it does not exist, run mkdir .paket.
Now do cd .paket so you're in the hidden .paket directory under sublime-fsharp-package-master.
Now do ls and see if there's a paket.bootstrapper.exe file.
If it doesn't exist, then copy in the .exe files you downloaded earlier:
cp /Users/Username/Downloads/paket.bootstrapper.exe .
cp /Users/Username/Downloads/paket.exe .
Important: Now do cd .. to go back up to the /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/ directory.
Now instead of running /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/build.sh install, try running it as ./build.sh install. (And also try ./build.sh Install, since I'm pretty sure the capital I is necessary).
(BTW, If you're not familiar with the syntax that I used in steps 9, 10 and 11, where I used a single . or two dots .. in commands, those are a long-standing Unix idiom: . means "the current directory", and .. means "the parent directory".)
I just looked at the build.sh script that you've been running, and it seems to assume that you've done a cd into the package's base directory (the sublime-fsharp-package-master directory) before running the script. So that could explain why it was failing: you were running it from a different directory, rather than doing a cd first. Hence why I marked step 10 as important: I think that was the root cause of the problem.
I am trying to set up and run LibreCAD and I am following their Build From Source Guide.
At some point, and after installing QT and boost, I reach the step where it says this:
To change these default settings you have to create the file
scripts/custom-windows.bat and overwrite the different settings
without effect to the SCM (git). Example for
scripts/custom-windows.bat:
set Qt_DIR=C:\Qt\5.4
set NSIS_DIR=C:\PROGRA~2\NSIS
set MINGW_VER=mingw491_32
So I created a custom-windows.bat file and overwrote the settings. Now, and since I am working on 64 bit Windows, They are saying that I need to do this:
There are issues with the NSIS_DIR path on 64 Bit Windows. When NSIS
is installed in the Program Files (x86) folder and NSIS_DIR is added
to the PATH, something goes wrong in the build process.
In this case use the command dir /X \ and get an output like this:
09/02/2014 09:50 PM <DIR> PROGRA~1 Program Files
10/27/2014 12:33 PM <DIR> PROGRA~2 Program Files (x86)
08/16/2014 10:49 PM <DIR> Qt
But what does that mean? "..use the command dir /X \ and get the output.." Where and how? Appreciate it if anyone could tell me how to solve that.
Open up a command prompt and literally type dir /X \. The output will show the mapping between the short folder names and the long ones.
Your goal is to use the correct short form representation for Program Files (x86) in NSIS_DIR, since it's not always PROGRA~2. It can vary from filesystem to filesystem, based on the history of the filesystem.
Suppose that I add a program to path that is dependent on a file name "test.in". I programmed this in C++ so I used ifstream fin("test.in") without specifying the directory. Now if I were to run this program from a different directory, would the program be able to access the file "test.in"?
Firstly, this has nothing to do with the file extension, which is merely a convention given as part of the filename.
Secondly, you were always using a relative path. Even when you were running your program "from the same directory" as test.in, you were reliant on the "working directory" of your shell context being the same as the directory in which the executable and the file reside.
This is not always the case.
For example:
~/myProject:# ls
test.in
program
~/myProject:# ./program
This is okay, because your shell is at ~/myProject, and so is test.in.
However, if you'd written:
~/myProject:# cd ..
~:# ./myProject/program
…then your test.in file wouldn't be found, as it does not exist in ~. It exists in ~/myProject. It doesn't matter that the executable itself is also found in ~/myProject.
This is actually desirable behaviour, as it allows flexibility from the shell. Ideally you would allow support for piping/redirecting the file to the process instead (program < test.in — now there are no assumptions baked into your code at all!), but we can save that for another day.
For now, you seem to be concerned about what happens if you move the executable away. Don't worry: just use this feature!
~:# mv myProject/program .
~:# cd myProject
~/myProject:# ../myProject
Your working directory is the directory in which test.in resides, so it will be found via the relative path given in your program code.
I have a bunch of C++ programs each in its own sub-directory. Each sub-directory has a single C++ program in several files -- a .h and a .cpp file for each class plus a main .cpp program. I want to compile each program placing the executable in the corresponding sub-directory. (I also want to run each program and redirect its output to a file that is placed in the corresponding sub-directory but if I can get the compilation to work, I shouldn't have a problem figuring out this part.)
I'm using the bash shell on a UNIX system (actually the UNIX emulator Cygwin that runs on top of Windows).
I've managed to find on the web, a short scrip for compiling one-file programs in the current directory but that's as far as I've gotten. That script is as follows.
for f in *.cpp;
do g++ -Wall -O2 "$f" -o "{f/.cpp/}";
done;
I would really appreciate it someone could help me out. I need to do this task on average once every two weeks (more like 8 weeks in a row, then not for 8 weeks, etc.)
Unless you're masochistic, use makefiles instead of shell scripts.
Since (apparently) each executable depends on all the .h and .cpp files in the same directory, the makefiles will be easy to write -- each will have something like:
whatever.exe: x.obj y.obj z.obj
g++ -o whatever.exe x.obj y.obj z.obj
You can also add a target in each to run the resulting executable:
run:
whatever.exe
With that you'll use make run to run the executable.
Then you'll (probably) want a makefile in the root directory that recursively makes the target in each subdirectory, then runs each (as described above).
This has a couple of good points -- primarily that it's actually built for this kind of task, so it actually does it well. Another is that it takes note of the timestamps on the files, so it only rebuilds the executables that actually need it (i.e., where at least one of the files that executable depends on has been modified since the executable itself was built).
Assuming you have a directory all of whose immediate subdirectories are all c++ programs, then use some variation on this...
for D in */; do cd "$D";
# then either call make or call your g++
# with whatever arguments in here
# or nest that script you found online if it seems to
# be doing the trick for you.
cd ../;
done;
That will move in to each directory, do its thing (whatever you want that to be) and then move back out.
Crossbridge allows you to compile C/C++ programs to target the flash runtime. It comes with its own modified gcc within cygwin. Since SDL only provides developmental zips for VC or mingw, I'm trying to compile SDL within this cygwin environment. However Crossbridge's gcc is version 4.2.1 and according to google searches SDL cannot be compiled with gcc versions higher than 3 inside cygwin. When I run ./configure, it fails with:
*** Your compiler (/cygdrive/c/Users/Tom/Desktop/Crossbridge_1.0.1/sdk/usr/bin/g
cc.exe -jvmopt=-Xmx1G) does not produce Win32 executables!
When I just type gcc alone, I get:
bash: /usr/bin/gcc: cannot execute binary file
Does it make a difference if I compile SDL using one compiler (i.e., a lower version of gcc) and attempt to use it with the Crossbridge compiler?
Is there a workaround for this?
I checked the Crossbridge_1.0.1.zip, cc and gcc maybe are broken link (only 56 bytes?) but the gcc-4 seem to be good.
edit
type gcc-4 as you typed gcc from the bash and you'll see the usual expected no input files gcc's error message, try gcc-4 -v
the message Your compiler does not produce Win32 executables is given by the fact that whatever you've executed (or has been executed automatically) is using /cygdrive/c/Users/Tom/Desktop/Crossbridge_1.0.1/sdk/usr/bin/gcc.exe as your compiler, but as you already checked it doesn't work, and if you check it with ls -l /usr/bin/gcc.exe you'll see that this is only 56 bytes size, this can't be the real compiler, I guess it probably was a symbolic link to the real compiler, which for some reason isn't working as expected (on linux executing a symlink is as executing the real binary).
I'm not an expert of cygwin, but I guess at some level symlink are supported, reading this FAQ make me wonder if some attribute hasn't lost packaging/unpackaging the zip, so that the symlink aren't recognized.
Try to recreate it (it worked for me):
cd /usr/bin # change directory
rm gcc.exe # remove the broken link
ln -s gcc-4.exe gcc.exe # re-create the symlink
run gcc again, should return the no input files error as expected.
But this isn't the solution, because probably in the unzipped files there are many broken symlink.
I can't believe Adobe is distributing a broken SDK, so perhaps there's some instruction somewhere about how to properly unzip the SDK preserving the symlinks (maybe unzip have a preserve attribute option? I don't know much about zip sorry.
edit
execute the run.bat (the bash) and cd to the main directory where you unzipped the SDK (mine is /cygdrive/c/crossbrige)
cd /cygdrive/c/crossbrige
for f in $(find ./ -type f -print0 | xargs -0 grep '!<symlink>' -l); do attrib +S $f; done
this should hopefully fix all the broken symlink, the only side-effect is that any file containing !<symlink> will get set the attribute DOS SYSTEM, but cygwin check both this magic string at offset 0 and the S attribute to consider a file as a symlink, so hopefully will not break anything.
I used Alex find/ attribute loop to fix all broken links in my cygwin install. I have no idea why they appeared.
The first attempt failed with messages like:
Invalid switch - /usr/lib/terminfo
for each file attrib worked on.
Turned out that for my cygwin/Windows combo I had to cd into the directory and execute attrib from there. So the loop content was:
do cd $(dirname $f); attrib +S $(basename $f); done