I'm currently building a electron app an building the installer like .deb and .snap with electron-builder. Inside the app I need the access the user home directory for some reason and I'm using process.env.HOME || process.env.USERPROFILE to get the home directory (also app.getPath('home') returns the same). This works properly for other cases but when the app installed with .snap, instead of the actual home(/home/username) directory this returns ~/snap/<app_name>/3/ as home directory. (3 is the snap revision number)
How do I get the actual home directory(/home/username) in all cases ?
Note that ~/ is not a valid path; it is expanded to $HOME by the shell. The actual path you're looking for will be /home/username in most cases. A simplistic solution would be to simply assume that to be the home dir.
To safeguard against situations where the home folder is not at this location, we should ask the operating system:
os module
const os = require("os");
const user_name = os.userInfo().username;
const user_dir = os.userInfo().homedir;
console.log(user_name, user_dir);
From the NodeJS docs:
The value of homedir returned by os.userInfo() is provided by the operating system. This differs from the result of os.homedir(), which queries environment variables for the home directory before falling back to the operating system response.
posix module
(original answer) If for some reason the above does not work, you can explicitly use getpwnam to look up the actual home directory from /etc/passwd:
const posix = require("posix");
const os = require("os");
const user_name = os.userInfo().username;
const user_dir = posix.getpwnam(user_name).dir;
console.log(user_name, user_dir);
You will need to install the posix module first:
npm install posix
Related
When I start my development rails server I get this following message first. To my knowledge WSL2 is a virtual environment.
I would have expected it to now reference a Java directory that resides on my Windows host. Is this likely something I carried over in the project from when I was using WSL1? How would I safely correct this?
/home/daveomcd/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/railties-6.0.3.2/lib/rails/app_loader.rb:53:
warning: Insecure world writable dir /mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath
in PATH, mode 040777
I experienced the same problem when trying to fix the slowness of WSL2. The recommended solution was to move the files from the mounted NTFS drive to the root ext4 filesystem (using \\$wsl\<distroname>), so I did that.
I set up /etc/wsl.conf as below:
# Enable extra metadata options by default
[automount]
enabled = true
root = /mnt/
options = "metadata,umask=0033"
mountFsTab = false
[interop]
enabled = true
appendWindowsPath = true
And ran rails bundle to update dependencies.
Also make sure that your file permissions and owner settings are updated. Hope it helps.
Sorry, I'd love to make this more of a comment to see if I'm on the right track before committing to an answer. However, since there's too much info here for that, I'll make an attempt at getting you an answer here.
While it is a virtual environment, by default WSL provides several "Windows Interop" features that allow it to:
automatically mount Windows drives in /mnt/{c,d,...}
append the Windows path to the Linux path
run Windows executables inside Linux
share Windows environment variables with Linux (although this is not something that happens by default)
I can't be sure (long, long time since I've used Rails), but it looks like something in the app_loader.rb is checking permissions on Java directories in the path. It may be using some logic like "check each path entry and look for a java or java.exe there. If found, check permissions." Or something like that. That means that (2) and (3) above may be confusing it.
You can see this in action with which java.exe, which will likely return a Windows path. Or run notepad.exe, which will launch the Windows Notepad executable from within Linux/WSL (magic! 😉).
These are both very useful features, so I hate to disable them completely, but it's the easiest way to figure out if that's the problem. Create a /etc/wsl.conf with the following contents:
[interop]
enabled=false
appendWindowsPath=false
Exit your WSL instance and then:
(from PowerShell, CMD, or Windows Start) Run wsl --list --verbose to see the name of your distribution (most likely Ubuntu)
Likewise, run wsl --terminate <distro> to terminate that distribution.
Restart your WSL instance
Try running /mnt/c/Windows/system32/notepad.exe (assuming a normal C:\Windows installation) (should fail, since interop is disabled)
Try which notepad.exe (should fail, since the Windows path should no longer be appended to the Linux path)
Try to start your Rails dev server again - Might work (might not, I could easily be wrong about the root-cause here)
If it does work, then you can try to correct the situation with several less invasive methods than disabling those features entirely:
If you plan on only using WSL for your development, then you could remove the Windows JDK.
Or at least remove the Windows JDK from the PATH in Windows.
Or, if you want to keep it installed and in the Windows path, you could have a shell startup file (e.g. .bashrc) that removes it from the path only in WSL. I'll point you to this question which contains multiple techniques for doing so.
Or you could keep the appendWindowsPath=false in your /etc/wsl.conf but then add back in the paths you want manually in your startup config.
I'm the author of dshell a dart package and tooling for building cli applications/scripts with dart.
https://pub.dev/packages/dshell
I'm looking into how dshell should interact with sudo.
The first problem I've come across is how do deal with paths.
If I do a pub activate global dshell, then dart installs dshell and its executables so that they are on the linux path for the current user.
This works fine until you try to run a dshell script using sudo.
e.g.
sudo dshell main.dart.
The sudo command essentially changes the user to the root user. As such the PATH variable changes and the HOME var changes. The result is that the dart and dshell paths are no longer on the path.
Is there a best practice for putting a dart package on a global path so that it (and its dependencies) are available to root and other users?
I have an unusual situation. I have a perfectly functional kivy app. Essentially, it uses FileChooserIconView and takes the root
`FileChooserIconView:
filters: [root.selected]
size_hint: (1, 0.4)`
so that with this function
`def selected(self, directory, filename):
# This function extracts the selected folder using
#the information from FileChooser
# This function takes as input:
# -filename: The filename of each file in each directory
# This function gives the output:
# -the full path to the directory with the selected folder
self.ids.mypath.text = os.path.join(os.path.dirname(filename), '') `
I can extract the directory of interest (rather than every single file in the directory).
The app extracts the directory of interest with FileChooser and uses it to extract all files there recursively and process them.
It works perfectly in Spyder in Windows. I package it in Windows and it works perfectly as an independent exe (finds all files that it needs for uploading and works perfectly).
It works perfectly in Spyder in Mac. However, I package it in Mac and it is completely unable to find the local files. This is my problem. Once packaged in mac, instead of looking for the local files in the dist folder, it looks for them in the mac home directory. It requires to read a file that is actually in the dist folder, but the app does not look for it there. It looks for it in the mac home directory.
I have tried to put the current directory where the main.py is (in the dist folder) using several methods, including
filename = inspect.getframeinfo(inspect.currentframe()).filename
path = os.path.dirname(os.path.abspath(filename))
from the question
How to properly determine current script directory?
but still it looks to the mac home directory instead of the directory where the main.py is.
I tried to change directory using the path above, but still goes to the mac home directory.
When I use print(os.getcwd()) in the main.py file it prints the correct directory when used in Spyder, but it goes to the mac home directory after packaging. I am really stuck and I could not find a similar question.
Any help much appreciated.
Thank you very much for all the comments, especially John Anderson who put me in the right track. They made my search much easier.
Finally, I solved it.
When you package an app you should reference the location of the main.py. I was using __file__ and, when the app is not packaged, that works and that is why it worked in Spyder. However, when the app is packaged, the correct way to find the main.py folder is sys._MEIPASS
That it is, as simple as using sys._MEIPASS
For more detail, the link https://pyinstaller.readthedocs.io/en/stable/runtime-information.html#using-file-and-sys-meipass provided by John Anderson is great.
Reinstalled Windows 10 (Version 10.0.14393). Reinstalled the following:
Java
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
nodejs (v6.9.5)
NPM (3.10.10)
Yarn (v0.19.1)
Yeoman (installed with yarn global add yo)
When I write yo -v in cmd in any folder, runned with administrator or not, I take:
The filename, directory name, or volume label syntax is incorrect.
UPDATE:
The only workaround I found is to use the full path of yo:
C:\Users\<username>\AppData\Local\Yarn\config\global\node_modules\.bin\yo.cmd
It may be that your PATH does not point to global NPM modules yet. The FAQ and links are more helpful for gnu/linux or mac users. The PATH is a list of the places that your operating system checks whenever you type a command.
Since you are using Windows, to add the modules path temporarily (just for one session) at the prompt, just type (obviously use the correct path with your correct username and please take note of the ; separator character):
path = %path%;C:\Users\<username>\AppData\Local\Yarn\config\global\node_modules\.bin\
You should then be able to run 'yo -v' without pointing to the full path name, since the console now knows to check that folder also. If that works for you, you can add that path permanently using the instructions described on another SO post here.
Finally (and this is only slightly related to your question), since i notice you've got the Windows 10 anniversary update, if you have Linux experience, you may prefer to use "Windows subsystem for Linux", which is a bash shell (Ubuntu 14) on Windows, that you can use instead of the default command prompt. You can find it under "Add / Remove programs --> Turn Windows features on or off --> (scroll right down) --> Windows subsystem for Linux (beta)". Your local file system will be at "/mnt/c" so you can get to it from within the shell or from windows explorer. I've had fewer problems using this and since so many tutorials are written with bash (not command prompt) in mind, it's useful to use it instead of cmd.
You'll need to install dependencies in the usual way using apt-get (as it won't use the ones you've installed on the windows side) and you'll need to prefix commands that make system changes with 'sudo'. e.g.
sudo npm -g modulename
I had an app using chromedriver on a Linux machine, and I switched the app over to a Windows 10 machine. Now suddenly it's telling me that it can't find the chromedriver file.
Here's error:
Selenium::WebDriver::Error::WebDriverError in Static#home
Showing C:/Users/User/Documents/test_app/app/views/static/home.html.erb where line #4 raised:
Unable to find chromedriver. Please download the server from http://chromedriver.storage.googleapis.com/index.html and place it somewhere on your PATH. More info at https://github.com/SeleniumHQ/selenium/wiki/ChromeDriver.
I placed the chromedriver file in the same place it was on my Linux machine, right in the main folder of the app. In this case the path is C:\Users\User\Document\test_app. Does Windows interpret paths differently than Linux?
The chromedriver is the latest release. It's titled "chromedriver_win32.zip". The "win" means Windows. Could the "32" mean it's for a 32-bit system? My machine is 64-bit.
If you put the chromedriver.exe in the folder Chromedriver_win32.zip which is in the same folder as your script, you can set the driver_path to that file. See code below:
require "selenium-webdriver"
Selenium::WebDriver::Chrome.driver_path = File.join(File.absolute_path('./', "Chromedriver_win32.zip/chromedriver.exe"))
driver = Selenium::WebDriver.for :chrome
driver.get "https://www.google.com.sg/"
I don't have any knowledge on ruby or ruby-on-rails. please find the equivalent in java or python in Windows OS.
Two ways:
you can keep Chrome driver in a place where it is added to PATH variable (environment variables in Windows 10)
Programmatically set the path to the executable chromedriver.exe
For Java:
System.setProperty("webdriver.chrome.driver", "/path/to/chromedriver");
For Python : (we keep chromedriver.exe in C:\Python27\Scripts location. this location is already added to PATH variable when python (Activestate) is installed. in case, chromedriver.exe is not in one of the PATH locations, you can specify as follows)
driver = webdriver.Chrome('/path/to/chromedriver') # Optional argument, if not specified will search path.
For Ruby:
Add the ruby installation path to Windows PATH environment variable and keep chromedriver.exe in that location. (Windows searches for binaries in the locations specified in PATH variable.)
For more info on setting ruby installation location to PATH
https://stackoverflow.com/a/26947536
References:
https://sites.google.com/a/chromium.org/chromedriver/getting-started
I would put this in as a comment, but, since I'm relatively new, I am forced to put it in as an answer, which it might well be...
Pardon me if I'm asking the obvious, but, did you try "unzipping" the file and putting the ".exe" file into that directory? The file you mentioned (you said.. titled "chromedriver_win32.zip") is not an executable file in Windows. The file you should be looking for is chromedriver.exe.