I'm using electron to develop an app. I'm using shell.writeShortcutLink() to create a shell link shortcut in the start menu. I need the start menu shortcut to enable windows toast notifications. I also create a normal shortcut on the desktop.
For some reason when the app is launched with the shell link in the start menu my app's process.execPath is changed to C:\Windows\System32 instead of the expected real location of the executable. The normal link works fine and process.execPath is correct.
This is a problem because I use process.execPath to access a file in the same folder as my app. Is this normal behavior for a shell link? Do apps launched with a shell link default their execution path to the System32 folder or is this something that is wrong with electron?
I suspect you're not setting the cwd param of the ShortcutDetails passed to writeShortuctLink. If the working directory isn't set on a shortcut, the default is c:\windows\system32
Related
I tried to run a .sh file in my terminal and accidentally opened it in vscode, now it always opens in vscode even though i want to run it in the terminal itself.
I tried uninstalling vscode so i can get the option to choose again, but that didn't seem to work. I'm too scared to play about with the JSON file incase I mess something up as this is a school project.
Just change the default app for the .sh file type. After that, .sh files won't open by vs code.
To do this in windows 11
Search For Default Apps on start
Scroll to the bottom and click Reset All Default apps
This will reset all the default apps and you can set the defaults again
I have a situation in which I wanted to utilize the camera app in Windows 10 from my Microsoft Access program. Normally I could just send a command to execute the program's executable, but with the metro app there is no straightforward executable.
The basic code I use is this:
Shell """" & PthToExe & """", vbNormalFocus
PthToExe is the path name for the executable.
I looked around a decent bit, but was unable to find any simple solutions and ended up coming up with my own. My solution is to make a shortcut link to the camera application and then to launch the link.
In order to make a shortcut link in Windows 10, you can click on the start button, go to "All Apps", find the app you want (in my case "Camera"), and then click and drag it to the desktop.
Now that you have a shortcut, you can launch the shortcut from a command line. (So my shortcut doesn't clutter up my desktop, I dragged it off my desktop and into a folder on the "C" drive.)
Type the path into a command prompt like this and hit enter to test launching your app: C:\GJ\Camera.lnk
So that solves the problem if you wanted to launch from a command line. For some reason, though, Access would not accept that command. The way I got around it was I put the command in a batch file (Edit: Alternatively, see HansUp's comment). To do that, you just need to open notepad, type in the same thing you typed in the command prompt, save the note pad document, and then rename the document to have a .bat extension.
You can then execute the .bat file from Microsoft Access as follows:
Shell "C:\GJ\OpenCamera.bat", vbMinimizedNoFocus
Note that normally, I use vbNormalFocus when running the shell command, but in this case, it is desirable not to see the little command prompt open before the actual program opens.
I'm on MacOS X, and I'm pretty new to app-bundle-type things. I am writing a program that opens a window and registers mouse input -- not a command line tool. When I compile my code (written in C, if that is important) into an executable file (a "unix executable file") and then run that file directly (by double clicking it, for example), a terminal window pops up, and then the program's window pops up. Likewise, if I navigate to the directory of the executable and open it from the command line, it pops open /another/ terminal window and then the program's window.
However, if I wrap the executable in a bundle (thus, I suppose, turning it into a proper "app"), then when I run the app, either by double clicking or from the command line, the program's window opens and no new terminal window is created. Is this merely a property of the "app bundle"'s architecture? Or is there a way that I can run the raw executable without incurring another terminal window? I suspect that I'm misunderstanding something fundamental. Thanks in advance!
I believe what you're seeing is correct. In order for a separate window to not pop-up, you'd need to encapsulate it into a bundle.
Launching by double-clicking a bundle, or using the 'open' command from Terminal uses Apple's Launch Services, which maintains a list of known (registered) applications. When an application (bundle) is introduced to the system, it is registered with Launch Services and associated with its URI (e.g. com.apple.calculator), which is present in the bundle's Info.plist
Other items in the Info.plist tell launch services how to handle the application, such as checking if the minimum or maximum version of the OS has been exceeded, or whether or not to display a dock item.
A lone binary doesn't have an associated Info.plist manifest, so its behaviour can't be varied and a Terminal window is opened.
Bare executable files are essentially treated as documents by Launch Services (the framework that the Finder, Dock, and open command use when you open stuff). The application which handles such documents is Terminal. So, when you open an executable in that fashion, it launches Terminal if it's not already running and tells it to open the document. Terminal does this by opening a new shell window and auto-typing the path to the "document" as a command line.
Launch Services handles bundled apps as, well, apps. If the app is already running, it activates it and possibly has it open a new untitled window. Otherwise, it launches it.
As Rob Napier notes in the comments, if you run an executable directly from the command line (or if some already-running app launches it using NSTask or fork+exec), it will simply run. Launch Services won't be involved, so Terminal will not be asked to open the executable as a document.
My current use of iTerm is the following everytime:
- Open up
- cd into my project folder
- open up another tab
- cd into my project folder
- Grunt Watch
- open up another tab
- SSH into live server
This is getting a bit tedious now, is there a simple way to make a one click for all of this to be done? I remember back in the windows days you could create custom command prompt files so it would open up and you could just double click it like an app.
Is there anyway I can do this? I have looked at the profiles and I don't think I can do what I am after with that.
Just need pointing in the right direction.
If you're using iTerm2, there is a feature called Arrangements (see the last entry on the page). With this, you can set iTerm to open a series of profiles (which can be set to run a command at startup, start in a specific directory, run a certain shell, etc.).
It seems that creating one profile for working in a directory, a second for the Grunt Watch, and a third to SSH should be trivial, and once the arrangement is saved, it can be recalled with the press of a hotkey (Cmd⇧R on my install). You can also set this to save split-pane windows if you don't want a separate window for each of these tasks.
I have a type of data file associated with my program. I can run my program by clicking on a shortcut, or by double-clicking on the data file. Standard Windows stuff.
However, I need to be able to set the Starts In folder to a specific folder. Everything is fine when I use the shortcut (because that has a Starts In parameter), but when I double-click on a data file, the Starts In defaults to the local folder of the data file, which is not what I want.
To be more specific, I'm using a network dongle protection system (Safenet SHK) that requires an XML file to be in the Starts In folder before the protection shell allows my code to be run, so I can't just change the folder in my program, because it hasn't run yet.
What can I do?
You could create a launcher application. This application would do nothing but set the working directory and then start the real application and pass in the name of the file the user is trying to open. Your application shortcut can point to your main application, but the file associations you create would use the launcher.