My Windows application is frequently used on *nix using Wine.
As it is a file-centric application, it frequently uses (and presents to an user) Windows "documents" folder (as resolved using CSIDL_PERSONAL). Unfortunately under Wine that points to fake Wine/Windows directory that's usually empty and unused. I'd like to point user to his Unix home folder instead.
Is there any reliable way to find out its location under Wine?
I was hoping I can read HOME environment variable, but it's not exported (contrary to most other variables) to Windows environment.
Currently I'm guessing the home using Z:\home\%USERNAME%. But that does not look robust to me.
If there's no way to find home directory, is there at least a way to detect Wine root drive (Z: by default), so I do not need to hard-code at least a drive-part of path?
For a lack of better answer, I'm sharing my current workaround/hack:
For *nix platforms, where I have deployment under control (OS X particularly), I copy the HOME environment variable to another variable from a startup script (say the WINE_HOME). Most environment variables (with notable exception of the HOME) are exported to Windows/Wine environment. So I can read the WINE_HOME from my application, prepend Z:\ and convert slashes to backslashes.
For platforms, where I do not have deployment under control, I can use the USERNAME variable only to guess the home as Z:\home\%USERNAME%. This particularly does not work on OS X, where the home is in the /users not the /home.
EDIT: I found a question Get Wine path of file that helps a bit. In *nix you can use the winepath -w ~ to get Z:\home\username. But running the same from Windows environment does not resolve the ~. You can at least run the winepath -w /home/username to get Z:\home\username to find out a drive of the Wine root (in case it's not the default Z:\).
In Wine drive Z: always maps to the root (/) hence your way of detecting is cool. But if the user does
rm ~/.wine/dosdevices/z\:
this won't work of course. In wine mailing this there was a discussion about the security implications of Z: mapping.
Related
I have a .netcore application which reads the log path from appSettings.json.
I want to provide the default path to be something like %HOME%/MyApp/Logs/Log.json.
My code reads and expands the environment variable using Environment.ExpandEnvironmentVariables.
Now the problem is this works on Mac but on windows %HOME% is not expanded. Rather %userprofile% works on Windows.
My question is- can you suggest me some environemt variable that will work on both the platforms? As I said it reads from json, so there is not much option for me to check the platform it's running on.
I am using Microsoft's OneDrive for Business provided by our university to sync big junks of data. I'm also using using a software to run some simulations which is not available for windows and I have to use WSL. Now the issue is that OneDrive folder name is like OneDrive - University of foobar and the software I'm using refuses to accept path names with spaces in it. Unfortunately as far as I know Microsoft has made it impossible to change the folder name for OneDrive for business. I have to find a way to fool WSL to think the folder name is different. something without spaces!
What I have tried:
I have tried ln -s link target but when running the software it considers the original folder
I have tried mount --bind link target but it behaves weirdly and I didn't get what I needed
I also tried the windows side using mklink /D link target it did not work either.
I would appreciate if you could help me know if there are any solutions to let the WSL see the folder name differently.
Wrong solution
Thanks to this post on Reddit I was able to solve this issue. I was using ln in a wrong way. The correct form is:
ln -s /target/path/with\ spaces/ /path/to/link/file
where file must not exist beforehand. Now WSL treats file as the target folder!
Can anyone please guide me setting up the path in rstudio, why I cant change present working directory. what if I want to save a file on desktop and pull up the file in Rstudio.
Your help is appreciated.
thanks, sandy
Some of the most common reasons I have found where setting directory was a problem with the solution
Forgot the "" marks around the path example of correct setwd("Libraries/Documents")
Working in Windows and forgot to switch the back-slash to a forward slash, examples: WRONG-> "Libraries\Documents" RIGHT->"Libraries/Documents"
There path is on a shared system where they system denies that access (we have remote folders on servers at work that cannot be addressed this way)...IT security
The directory is not actually mapped as you stated, example possibly you do not need the Libraries part or you have to expressly include another level of folders above your current address
The directory has a different name, a capital letter, a space in it or something making addressing it on your system difficult
You are actually already in the wanted directory. as joel said, try getwd() to see where it says you are.
If none of this is your problem, post the error message and your system (linux, OS10.?, Windows 7 pro) and they setwd("path_to_stuff") you are using and we can try to get to the heart of the matter better.
I am looking for an R function to return an identifier of the computer the script is being run on, or at the least to distinguish between one of two known computers.
I have two PCs, both running Windows and RStudio. I use the desktop in the office and the laptop over VPN, typically working on the same projects, always using RStudio.
My scripts and permanent data sets are in a commmon repository. However, since I/O to that repository is slow, I keep a local directory for temp files.
On the desktop, I have a dedicated drive, and each project lives in its folder 'D:/workspace/this_project/'. On the laptop, the path is 'C:/Users/myself/Documents/workspace/this_project/' or just '~/workspace/this_project/'.
Currently, I keep two setwd() statements at the top of each script, and I just rely on the fact that one of them will fail because of the file structure.
setwd('~/workspace/this_project') # will fail on the desktop
setwd('D:/workspace/this_project') # will fail on the laptop
This seems like a bad practice.
I've looked through ?"environment variables" and don't see how to get my computer's name on the network or something else that is persistent and unique to the computer.
The desired solution could modify the laptop's tilde expansion to D:/ on the laptop only so that a common '~/workspace/' could be used, or a function using_laptop() like this:
set_project_wd <- function(folder_nm){
if(using_laptop()) setwd(paste0('~/workspace/',folder_nm))
else setwd(paste0('D:/workspace/',folder_nm))
}
If you call Sys.info() you can get your details:
names(Sys.info())
[1] "sysname" "release" "version" "nodename" "machine" "login"
[7] "user" "effective_user"
the entry under nodename will be your pc name.
Then you can do something like:
set_project_wd <- function(folder_nm){
if(Sys.info()[[4]]=="mylaptopname") setwd(paste0('~/workspace/',folder_nm))
else setwd(paste0('D:/workspace/',folder_nm))
}
JWrapper support now redirects to StackOverflow, so I'm posting here.
The Windows shortcuts created by JWrapper don't work; they point to a location which doesn't exist; I can verify this by navigating to the directory pointed to in the properties of the shortcut:
C:\Users\jchrist\AppData\Roaming\JWrapper-SampleApp
and seeing that the expected SampleAppWinLauncher.exe isn't there.
I can reproduce this simply with a slight modification of the SampleApp. Open the jwrapper-sampleapp.xml file and copy main virtual app, but give it a different name:
<App>
<Name>SampleApp2</Name>
<LogoPNG>sampleapp/logo.png</LogoPNG>
<MainClass>jwrapper.SampleApp</MainClass>
<Param>one</Param>
<Param>two</Param>
</App>
If you do this, and then run the 32-bit offline installer, you'll get a dialog which allows you to select which of the two virtual apps you want to launch.
After selecting one of the (identical) virtual apps and quiting it, the shortcuts provided in the start menu in the SampleApp folder do not work. If you dig into the properties of the shortcuts, you can see they point to an executable which doesn't exist. (It did exist, but it deletes itself after the first run).
I'm using the latest JWrapper (jwrapper-00036138363.jar, although this problem existed with jwrapper-00035090611.jar) as well.
I've tested this on Windows 7 today and it works OK. I haven't tested this on server 2008 but Windows 7 is treated basically the same as Server 2008 by JWrapper. Also the executable disappearing after the first run is not normal behaviour.
My guess would be that this is antivirus software that is detecting the run as a false positive and deleting the executable. Do you have any AV software installed? can you turn it off to test?
Unfortunately some AV software will delete files etc without any warning.