I need to make my Autohotkey scripts run at startup, so I think the best way is to save the file .exe in the startup folder, but the .exe file is saved automatically in the same folder of the source, so save the source in the startup folder could be a solution too, but it also opens the source at startup.
Now I'm using the syntax highlight plugin for autohotkey in SublimeText3, but I don't know if there are some way to save the .exe file to a different folder than the one where the source (I'm a noob in informatic).
I'd tried using SetWorkingDir in the Autohotkey script and costumizing the AutoHotkey.sublime-build file using working_dir, but I don't know how they work, so I didn't achieve the goal.
I need a way to edit .ahk with Sublimetext3, keeping my scripts in "documents" and, when I build, save the exe in another folder.
If you're just looking to have your AHK files load when you start up Windows, then the Startup folder is indeed the right location. An elegant solution would be to call the other scripts from this main script.
Since the default AutoHotkey.ahk script is contained in your Documents folder, you can include or run various other AHK scripts, depending on whether you want them to run under one AutoHotkey instance, as one per script, or some combination of the two.
Documentation on Include is fairly solid. The example from the linked page:
#Include C:\My Documents\Scripts\Utility Subroutines.ahk
#Include %A_ScriptDir% ; Changes the working directory for subsequent #Includes and FileInstalls.
#Include C:\My Scripts ; Same as above but for an explicitly named directory.
Similarly, you can Run like below:
Run, C:\My Documents\Scripts\Utility Subroutines.ahk
I am not sure I understood well your question. (Maybe you could make it clearer)
To run an .ahk at startup you can save it in your startup folder and you need simply to associate .ahk with the AutoHotkey.exe. (Always open with AutoHotkey.exe). You don't have to have the 2 files in the same location.
You could also add a shortcut to your .ahk file to your startup folder.
If you have many scripts copy each shortcuts to the startup folder.
Related
When running an interactive session, PyCharm thinks of os.getcwd() as my project's directory. However, when I run my script from the command line, PyCharm thinks of os.getcwd() as the directory of the script.
Is there a good workaround for this? Here is what I tried and did not like:
going to Run/Edit Configurations and changing the working directory manually. I did not like this solution, because I will have to do it for every script that I run.
having one line in my code that "fixes" the path for the purposes of interactive sessions and commenting it out before running from command line. This works, but feels wrong.
Is there a way to do this or is it just the way it is supposed to be? Maybe I shouldn't be trying to run random scripts within my project?
Any insight would be greatly appreciated.
Clarification:
By "interactive session" I mean being able to run each line individually in a Python/IPython Console
By "running from command line" I mean creating a script my_script.py and running python path_to_myscript/my_script.py (I actually press the Run button at PyCharm, but I think it's the same).
Other facts that might prove worth mentioning:
I have created a PyCharm project. This contains (among other things) the package Graphs, which contains the module Graph and some .txt files. When I do something within my Graph module (e.g. read a graph from a file), I like to test that things worked as expected. I do this by running a selection of lines (interactively). To read a .txt file, I have to go (using os.path.join()) from the current working directory (the project directory, ...\\project_name) to the module's directory ...\\project_name\\Graphs, where the file is located. However, when I run the whole script via the command line, the command reading the .txt file raises an Error, complaining that no file was found. By looking on the name of the file that was not found, I see that the full file name is something like this:
...\\project_name\\Graphs\\Graphs\\graph1.txt
It seems that this time the current working directory is ...\\project_name\\Graphs\\, and my os.path.join() command actually spoils it.
I user various methods in my python scripts.
set the working directory as first step of your code using os.chdir(some_existing_path)
This would mean all your other paths should be referenced to this, as you hard set the path. You just need to make sure it works from any location and your specifically in your IDE. Obviously, another os.chdir() would change the working directory and os.getcwd() would return the new working directory
set the working directory to __file__ by using os.chdir(os.path.dirname(__file__))
This is actually what I use most, as it is quite reliable, and then I reference all further paths or file operations to this. Or you can simply refer to as os.path.dirname(__file__) in your code without actually changing the working directory
get the working directory using os.getcwd()
And reference all path and file operations to this, knowing it will change based on how the script is launched. Note: do NOT assume that this returns the location of your script, it returns the working directory of the shell !!
[EDIT based on new information]
By "interactive session" I mean being able to run each line
individually in a Python/IPython Console
By running interactively line-by-line in a Python console, the __file__ is not defined, afterall: you are not executing a file. Hence you cannot use os.path.dirname(__file__) you will have to use something like os.chdir(some_known_existing_dir) to reference a path. As a programmer you need to be very aware of working directory and changes to this, your code should reflect that.
By "running from command line" I mean creating a script my_script.py
and running python path_to_myscript/my_script.py (I actually press the
Run button at PyCharm, but I think it's the same).
This, both executing a .py from command line as well as running in your IDE, will populate the __file__, hence you can use os.path.dirname(__file__)
HTH
I am purposely adding another answer to this post, in regards the following:
Other facts that might prove worth mentioning:
I have created a PyCharm project. This contains (among other things)
the package Graphs, which contains the module Graph and some .txt
files. When I do something within my Graph module (e.g. read a graph
from a file), I like to test that things worked as expected. I do this
by running a selection of lines (interactively). To read a .txt file,
I have to go (using os.path.join()) from the current working directory
(the project directory, ...\project_name) to the module's directory
...\project_name\Graphs, where the file is located. However, when I
run the whole script via the command line, the command reading the
.txt file raises an Error, complaining that no file was found. By
looking on the name of the file that was not found, I see that the
full file name is something like this:
...\project_name\Graphs\Graphs\graph1.txt It seems that this time
the current working directory is ...\project_name\Graphs\, and my
os.path.join() command actually spoils it.
I strongly believe that if a python script takes input from any file, that the author of the script needs to cater for this in the script.
What I mean is you as the author need to make sure you know the following regardless of how your script is executed:
What is the working directory
What is the script directory
These two you have no control over when you hand off your script to others, or run it on other peoples machines. The working directory is dependent on how the script is launched. It seems that you run on Windows, so here is an example:
C:\> c:\python\python your_script.py
The working directory is now C:\ if your_script.py is in C:\
C:\some_dir\another_dir\> c:\python\python.exe c:\your_script_dir\your_script.py
The working directory is now C:\some_dir\another_dir
And the above example may even give different results if the SYSTEM PATH variable is set to the path of the location of your_script.py
You need to ensure that your script works even if the user(s) of your script are placing this in various locations on their machines. Some people (and I don't know why) tend to put everything on the Desktop. You need to ensure your script can cope with this, including any spaces in the path name.
Furthermore, if your script is taking input from a file, the you as the author need to ensure that you can cope with changes in working directory, and changes of script directory. There are a few things you may consider:
Have your script input from a known (static) directory, something like C:\python_input\
Have your script input from a known (configurable) directory, use ConfigParser, you can search here on stackoverflow on many posts
Have your script input from a known directory related to the location of the script (using os.path.dirname(__file__))
any other method you may employ to ensure your script can get to the input
Ultimately this is all in your control, and you need to code to ensure it is working.
HTH,
Edwin.
Wording the title was a little tricky, but here's the situation. I am making a install.sh file for my game which is written in Python. I am trying to create a game folder with all assets instead of making this a module for Python. I may be doing things the hard way, but this method seems to work well.
The install.sh copies the game's directory to the HOME folder and moves a .desktop file and game's icon to the appropriate places (ie. desktop, applications folder). The issue is, this .desktop file uses Icon=~/.local/share/icons/game.png and Exec=~/Game/game.sh which causes the icon not to show up in the .desktop file or menu nor does the game shortcut execute. I replaced the ~ with $HOME and I get the same issue. However, if I change it to /home/(my account) instead of ~ or $HOME it will work perfectly and show the icon.
Is there a way to make the install bash file create this .desktop file dynamically if a user installs the game? Or is there some way of getting this to work that I am unaware of?
EDIT: Better explanation... ish.
Alternatively, put ~/.local/share/applications in the premade .desktop file, and then sed 's/~/$HOME/g' appname.desktop > $HOME/.local/share/applications/appname.desktop in the installer script, or invoke that from your language interpreter as a shell exec.
It's a real shame that more projects with GUIs don't do this. These desktop files also need a 'wmClass' element in them in order to allow for the launcher to also be a window tab. I've manually fixed several applications for my convenience this way.
Seems the easiest way was to include the files system-wide. While not my intention, it made it far easier to install all the proper files and get things works.
Putting the .desktop file in /usr/share/applications and icon file in /usr/share/icons/
I am trying to edit the corflags file so that I can run 32bit applications on a 64 bit pc but everytime I try to edit the file using something like corflags.exe assembly /32bit+ it comes up with the error message cf001 could not open file for writing.
Now I have tried a lot of different options such as:
Running in administrator mode;
Finding the file using a search and checking read only is not ticked
Checking that user full control is ticked
Tried to set the whole folder to non read only
When trying the whole folder, it goes through looking like it has set read-only, but then I click OK and re-right click on the whole folder, the box is filled in (not ticked) does this mean that part of the folder is read only and why does it reset to read only?
I just faced the same problem and have tried the same things.
Run cornflags from an elevated ("Run as administrator") Visual Studio Command Prompt. I did the same for a copy of the original .exe just to make sure no other process was using the program.
Create a copy of the file you intend to target with CorFlags.
(e.g. "WcfServiceHost.exe" --creates--> "WcfServiceHost - Copy.exe")
Rename the original file to something else:
(e.g. "WcfServiceHost.exe" --> "WcfServiceHose_Original.exe")
Rename to copy to the original file name
(e.g. "WcfServiceHose - Copy.exe" --> "WcfServiceHost.exe"
For my purposes, I created copies and named them describing their configuration:
Example:
WCFServiceHost_With32BitOn.exe
WCFServiceHost_With32BitOff.exe
Now I can destroy the WCFServiceHost.exe files and create them from these pre-modified copies. No more CorFlags operations necessary.
Note: this is basically a more verbose version of #RMalke answer and that answer should be marked as the answer.
I realise this is years later, but for anyone else looking, I found that the quickest way was to copy cmd and corflags.exe into the same folder as the one you want to edit. Then run cmd as admin from there.
I just installed WinGHCi. When I try to load an .hs file with Ctrl+L, it opens the file browser in C:\Program Files (x86)\Haskell Platform\2012.2.0.0\winghci which is where I installed this. I don't want it to go there by default, I keep my code files in a different directory on a different drive and I don't want to have to navigate to D:\MyPath\Haskell every time I load a file.
I tried to set the "Start in" field of the shortcut I use to launch WinGHCi but it changed nothing.
How can I make WinGHCi look in my own directory by default?
It opens in the last directory you opened a .hs or .lhs from.
Try opening something from the folder you want, exit, restart.
Did it restart where you were?
Try working like that for a while, and if you like it (I do) then you're fine.
If you really do want to go to the same place every time, perhaps there's a way.
I can't find any setting to control this, but the information is stored in the registy.
Mine is at
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Haskell\WinGHCi 1.0.6]
"WorkingDir"="D:\\Files\\Andrew\\prog\\haskell"
You can save your version of that as resetghci.reg:
To make your own, open regedit and first try the same location. If not, search for WinGHCi.
You can export that subtree but you get the whole lot including recent expressions etc, which I don't think you should reset. Save that as ghcioriginal.reg just in case. Edit away all the lines except WorkingDir and save as resetghci.reg
When you double-click it it will ask you if you're sure you want to add that info to the registry. Yes you are.
Untested:
What follows works on older versions, but Microsoft seem to be going off .pif files and the start command, and I'm not able to test this in Windows 7.
Make a text file called ghci.bat in the same folder as the .reg you made. In it put
#echo off
regedit resetghci.reg
start WinGHCi
You might need to specify the full path to WinGHCi.
The start command is the windows equivalent of making a background process from a shell prompt, so this should terminate immediately.
Make a shortcut to ghci.bat (it will be called ghci.pif) and set it to open minimised and put a nice lambda icon on it (nick it from the winghci executable).
Pop that on your desktop, start menu or shortcut bar, and when you use it, you'll be popped back to your standard location.
Assume a Visual C++ solution that outputs several executables. These executables are meant to be run in a certain order and with certain parameters -- and for this purpose there already is an ant build.xml script.
What would be a decent approach to integrating this ant script with VC++, such that the ant script will point against the recently output executables (.\Debug and .\Release folders) and ideally could be run directly from VC++, and dare I say with remote debugging.
I was thinking of using build post-events that populate a build.properties file with the output location of each executable, and let the ant script use this .properties file.
Any help on the matter would be great.
I'm not sure if there is a good answer for this. Perhaps you are not asking the right questions. From C++ you can launch anything, including scripts. I'm not sure what you mean by VC++ integration.
The generic answer would be:
save the output locations somewhere, doesn't matter where (file, registry, environment variables etc.)
retrieve them in the script before use
But depending on what you need, you could also try:
Output the same executables in the same folder structure. This way you can use relative paths.
Use a post-build event which copies the script in the output folder and make it use the relative path.
Instead of a script you can also try handling everything from the first EXE. Instead of an ANT script it could use a configuration file which specifies execution order and parameters.