I would write PROTON_FORCE_LARGE_ADDRESS_AWARE=1 to active LARGE_ADDRESS_AWARE for all executable on the wine bottle, if I were to use steam's proton. What's its equivalent command for standalone wine or lutris?
A quick look at the source code reveals these lines:
self.check_environment("PROTON_FORCE_LARGE_ADDRESS_AWARE", "forcelgadd")
if "forcelgadd" in self.compat_config:
self.env["WINE_LARGE_ADDRESS_AWARE"] = "1"
As such, it looks like the equivalent is WINE_LARGE_ADDRESS_AWARE.
Related
I use Google Drive Desktop for Windows 10 and rclone connected to Google Drive for Linux. I would like to have a folder containing Python scripts to use on whichever system I happen to be on.
On Windows, I can type into cmd.exe "(script) arg1 arg2 ..." and it will run.
On Linux, I am using python virtualenv, so I add a shebang to line 1 pointing to the environment I want to use. Something like #!/home/(username)/venv1/bin/python. Then from bash I type "./(script).py arg1 arg2 ..." and it runs fine.
After adding the shebang, when attempting to run the file on Windows again, it fails with an error "windows Unable to create process using /home/(username)/venv1/bin/python".
Some of my google fu search results say "WiNdOwS dOeSnT sUpPoRt sHeBaNgS" but it clearly is having an effect on running my script (Win 10 x64 Python 3.10). Other search results say something like "use /usr/bin/env (python version) and it will all work out".
Does anyone know the proper way to do this? I think the problem with the second solution for me is that I am using a virtualenv, not a system version of python.
I am trying to learn haskell using haskell koans https://github.com/HaskVan/HaskellKoans. The installation instructions found is not working and they look presumably for linux. I need help to get the koans working on windows.
If you look at the top of setup-koans, you'll see:
#!/usr/bin/env runhaskell
import Control.Monad (unless)
...etc
That first line with the hashbang indicates that a unix shell running this file as a program should pass everything that follows (the haskell source file, in this case) to the command specified (/usr/bin/env runhaskell in this case).
If you have a GHC installation, and runghc in your path, you should be able to remove that line and do runghc setup-koans.
You might also like to play with cygwin, or with a linux virtual machine (e.g. in docker) to familiarize yourself with this sort of thing.
I recently installed Cygwin on Windows 8.1, it works great but I can't execute file using the dot, for example "./hello.ml". I'm using the Windows's command prompt.
When I try using it, it show me that "." is not reconized. How can I make it works ?
Thanks.
You need to use the cygwin terminal or powershell instead.
The command interpreter doesn't think that your files are executable because they aren't one of the types that are recognized as binary executables. In general, Windows would use file associations from the registry to make things happen when you try to run a file. The cygwin terminal follows the unix-like convention and knows that your scripts are ml files and they are executable by using the ml interpreter, most likely from a #! at the top of your file.
I have a c# source file. Is there any way to put something like #!/usr/bin/env mono, so it will be compiled and then run as executable:
For python for example, i'll do like this:
#!/usr/bin/env python
In fact, what I want is to run the script without calling "mono the.exe", after compiling. I want something like "./the.exe".
EDIT: I just noticed you want to do this for a single source file—for a single source file. This is almost supported by the csharp REPL that ships with Mono. However, the REPL spits out a syntax error because it doesn't understand the shebang line and sees it as a preprocessor definition. If I misunderstood and you were talking about a compiled assembly, the below text still applies. /EDIT
You can't use shebangs, because .exe files produced by Mono are PE executables, just like on Windows. They contain CIL, not a script.
What you can do though is produce a small shell script that runs mono your.exe and use that, or you can use the Linux kernel's binfmts support, as outlined here.
I think you may be able to use update-binfmts to register mono as the interpreter for (compiled) mono programs.
Try update-binfmts --display and see if the output includes something like:
cli (enabled):
package = mono-common
type = magic
offset = 0
magic = MZ
mask =
interpreter = /usr/bin/cli
detector = /usr/lib/cli/binfmt-detector-cli
I have a Haskell script that runs via a shebang line making use of the runhaskell utility. E.g...
#! /usr/bin/env runhaskell
module Main where
main = do { ... }
Now, I'd like to be able to determine the directory in which that script resides from within the script, itself. So, if the script lives in /home/me/my-haskell-app/script.hs, I should be able to run it from anywhere, using a relative or absolute path, and it should know it's located in the /home/me/my-haskell-app/ directory.
I thought the functionality available in the System.Environment module might be able to help, but it fell a little short. getProgName did not seem to provide useful file-path information. I found that the environment variable _ (that's an underscore) would sometimes contain the path to the script, as it was invoked; however, as soon as the script is invoked via some other program or parent script, that environment variable seems to lose its value (and I am needing to invoke my Haskell script from another, parent application).
Also useful-to-know would be whether I can determine the directory in which a pre-compiled Haskell executable lives, using the same technique or otherwise.
As I understand it, this is historically tricky in *nix. There are libraries for some languages to provide this behavior, including FindBin for Haskell:
http://hackage.haskell.org/package/FindBin
I'm not sure what this will report with a script though. Probably the location of the binary that runhaskell compiled just prior to executing it.
Also, for compiled Haskell projects, the Cabal build system provides data-dir and data-files and the corresponding generated Paths_<yourproject>.hs for locating installed files for your project at runtime.
http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#paths-module
There is a FindBin package which seems to suit your needs and it also works for compiled programs.
For compiled executables, In GHC 7.6 or later you can use System.Environment.getExecutablePath.
getExecutablePath :: IO FilePathSource
Returns the absolute pathname of the current executable.
Note that for scripts and interactive sessions, this is the path to the
interpreter (e.g. ghci.)
There is executable-path which worked with my runghc script. FindBin didn't work for me as it returned my current directory instead of the script dir.
I could not find a way to determine script path from Haskell (which is a real pity IMHO). However, as a workaround, you can wrap your Haskell script inside a shell script:
#!/bin/sh
SCRIPT_DIR=`dirname $0`
runhaskell <<EOF
main = putStrLn "My script is in \"$SCRIPT_DIR\""
EOF