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!
Related
In linux machines, it is possible to access where a symbolic link is pointing to by using Sys.readlink function in R or readlink from the command line. Reading its documentation, we see that this is not intended for Windows shortcuts.
In Windows I have not been able to find a one liner to give me where the file points to. The closest I got was from this SO question that demonstrates the use of dir. While the output was not perfect I figured with some regex magic I could isolate the file path.
However when I tried system2('dir'), I received the error "dir" not found.
Is there (a better) way for me to access the file path of a Windows shortcut from R and why can't I use dir through a system call in R?
For anyone in the future finding this thread, the answer is fs::link_path() as pointed out by Edward Visel
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.
So I've installed Facebook's Nuclide on top of my Atom editor.
Seems it provides many features.
My problem is that when I setup a remote project folder, I cannot get find symbol functioning any more.
The alt+cmd+g will through errors instead of generating ctags file in the project folder.
I ssh to the server and manually ctags -R . in the folder.
However, inside Atom/Nuclide, cmd+shift+r complains no tags file...
Please help. Any clues welcome.
This functionality is provided by the symbols-view package, which ships as part of Atom. Unfortunately it reads from the filesystem directly, so it is not compatible with Nuclide's remote connection. There has been some talk of refactoring it to use Atom's service-hub (which is how Atom packages are supposed to talk to each-other).
If that happens, Nuclide could provide it with the information from outline view and it would be able to work remotely. The functionality would not be exactly the same but for most purposes it would be fine.
However, nobody has yet put in the resources to drive the refactoring home. Here is a recent effort; I hope it is completed.
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.
First off, I will acknowledge that I am aware of another similar thread on the topic of wkhtmltopdf, but it was not similar enough to resolve my issue. Here's the other thread: wkhtmltopdf
Second, I will say that I have successfully used wkhtmltopdf with a Drupal site on a dedicated server that I run, where I installed the libX11 and used the most recent static version of wkhtmltopdf. That's on a CentOS 5 system and it runs nicely.
So, I have another hosting arrangement and I need to get the wkhtmltopdf to work, because it does the most amazing job producing bookmarked PDFs. The PDFs are beautiful.
The hosting is cPanel. I determined that it is on a server that has CentOS 5.5. It is not a problem to drop the static wkhtmltopdf in the print module's lib folder. However, I get the following message back in the Drupal admin status reports page (admin/reports/status).
It says,
"wkhtmltopdf library
The currently selected version of wkhtmltopdf () is not supported. Please update to a newer version."
I have obtained all of the needed .so files for CentOS 5, based on what jockie provided in his answer in the other StackOverflow thread.
Can someone knowledgeable confirm that his list was complete?
The idea of a shell script wrapper seems interesting and appears could be done for Drupal, if the naming of the shell script is called something like "wkhtmltopdf-wrapper.sh".
I have tried to use the shell script code that jockie provided, in a shell script. I did place all of the .so files in a sub-folder called "lib". I confess that I do not know what such things mean, in the script:
export HOME="$PWD"
Can someone interpret for me, what $PWD means?
export LD_LIBRARY_PATH="$PWD/lib/"
I understand that the script is going to get the .so files with that line, yes?
And can someone interpret the following line:
exec $# 2>/dev/null
What I am wondering is, where does the actual pdf get output? I did run the script. It did not throw any errors. However, I did not see a resulting PDF file.
Also, jockie's directions are not totally clear or defined enough. He says, "(some of them are symlinks)" under the list of .so files. Are such lines (in his list), the symlinks?:
lib/libX11.so.6 lib/libX11.so.6.2.0
Or am I mistaken? I was able to get all of them, so I don't know why they would be symlinks. The only thing is, that some of the versions are different. Do I need to delete the following files and make symlinks instead?:
lib/libX11.so.6
lib/libXau.so.6
lib/libxcb.so.1
lib/libXext.so.6
Should the shell script code be written differently, with Drupal in mind?
Thanks for reading and I hope someone can help!
...Finally, if anyone knows of a better solution, please share! Again, I appreciate the help!
...There does not seem to be a way, here on StackOverflow.com to notify jockie to check out this thread. I wish there was a way to write to them or notify them, so that they could clarify for them-self or contribute to this thread as well. If someone knows of a way, please let me know that too!