I write Applescript and I try save "app" preferences (password). I can make this in file but I (think) must write full path to file :-/ How can I open a file without entering the full path or save and use in "preferences"?
set filePath to "macOS Sierra:Users:test:Desktop:pass.txt"
set pass to paragraphs of (read file filePath)
do shell script command user name theuser password pass with administrator privileges
I didn't downvote this question, but I do see that it has some problems.
The first step in writing a good question is to tell us what you searched for. What did you find? Have you made any progress toward a solution?
It would also "help us help you" if you added precisely what your goal is, what you tried, and what didn't work in your attempts. It's unclear, for example, why you want to store some data in a file, but then do not want to include the full path to that file.
Finally—and I say this in good faith and with your best interests in mind—your larger goal might perhaps be OK, but storing a plaintext password in a file is a very bad practice, on security grounds.
To move things forward, hopefully some of these will be directly applicable or helpful:
If you wish to store a password natively in the macOS keychain from an applescript, consider using the security shell command also via do shell script.
For an all-applscript route, I often see mentions of the third-party solution called Usable Keychain Scripting, an applescript-to-app-to-keychain interface. Note! It appears unmaintained, and is 12 years old!
You mentioned a 'preferences' file. If you wish to store data as key+value pairs, consider using macOS's ubiquitous preference-storage system, and its defaults command, again via do shell script. It will allow you to write and read preferences without a loose file on your desktop.
Lastly, to your direct question—again, you shouldn't do this with passwords!—but if you must reference a custom file, but do not wish to use a hard-coded path, applescript can find many folders by name using the path to it and expand the folder name into a full alias, e.g. tell application "Finder" to size of (file "myData.bin" of folder (path to desktop folder from user domain)). See the path to documentation for usage and a full list of named folders.
I have recently upgraded to Windows 10 from Windows 8.1.
Now I wanted to set an environment variable for my new installation of Apache Maven.
Each time I created the user variable, things were fine. However, I also need to create the system variable where I will need to append the bin directory to the variable that I already create in the user variable to be "path".
Now, each time I do this, I get an error that says "This environment variable is too large". As a result of this, I am unable to create the path.
I have attached an image of this error.
When the PATH environment variable gets overloaded with too many values it reaches a point where you cannot add values any more. Trying the following should solve your problem.
Solution 1:
Create a new system environment variable, say 'NEWPATH'
Assign the bin directory location to 'NEWPATH'
Now append '; %NEWPATH%' to the PATH environment variable
If this still doesn't work then try to copy some part of the PATH environment variable already existing values to the 'NEWPATH' and then append the 'NEWPATH'.
Solution 2:
Check the value of the PATH environment variable if you can group and shorten the paths. For example,
C:\Program Files\Microsoft SQL Server\102\Tools\Binn;C:\Program Files\Microsoft SQL Server\102\DTS\Bin;
can be combined to
C:\Program Files\Microsoft SQL Server;
In this way, you can build more space into your fixed length PATH variable and finally adjust your bin directory location into PATH.
There are a few ways to clean up your path variable. The easiest is to use Rapid Environment Editor. This free utility will,
Remove the duplicate paths (right click → Cleanup Paths)
Remove non-existent folders (shown in red which you need to manually delete)
Replace long paths with short paths (right click → long to short path).
I do the above steps in order and use the third step only for the longest paths until the Path variable size is under control again.
If you want to go more advanced, here's a little C# tool that you can modify to whatever other logic you want to implement.
Another solution, or more a workaround to bypass the PATH environment variable length limit, is to manage your path (add, remove or update) using a PowerShell script;
Capture the current PATH variable by clicking "Edit Text" (see above screenshot) and copy it to your clipboard and save it in a text file as a backup too to avoid bad surprises. This is not mandatory, but will allow you to recover should something go wrong.
Now that it is backed up, add the following to a new PowerShell (.ps1) file (amending the first line below with the folder path(s) you want to add (the part after the + sign):
$newPath = $env:Path + '; C:\Users\....\FirstFolderToAddToPath; C:\Users\....\SecondFolderToAddToPath;'
[Environment]::SetEnvironmentVariable("Path", $newPath, "Machine")
$env:Path = $newPath
This is how I managed to get my (long) PATH variable back after playing with the Windows 10 UI, being caught by the length limitation and losing most of my path.
Try to modify by RegEdit. In my case it works when length is more than 3000.
Press Win + R and enter regedit to open RegEdit. Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and modify the value of Path to your path. And restart the computer, and it should work.
In addition to the answer of Swapnil, note that you can modify the maximum length of the Path environment variable - which is otherwise limited to 2048 characters (while a single path has an historical limit of 206 characters).
In Windows 10, you achieve this by setting the LongPathsEnabled registry key to 1, which can be found here:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
To access the registry editor: Windows key + R, type Regedit.
Source: Windows 10 “Enable NTFS long paths policy” option missing
Also take a look at this Super User answer: An answer to Windows 10 “Enable NTFS long paths policy” option missing
Note that the error "Environment variable is too large" is related to the whole variable, not the single path currently being added (to answer the "inaccurate advice" comment below).
Additional note: app compatibility
The text in the registry key/group policy related to LongPathsEnabled reads:
Enabling NTFS long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node. Enabling this setting will cause the long paths to be accessible within the process.`
The caveat here is the term manifested. In general applications need to declare capabilities explicitly in a manifest file; most win32 applications since the days of Windows Vista are manifested. To use long paths, the app manifest needs a longPathAware element:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
<ws2:longPathAware>true</ws2:longPathAware>
</windowsSettings>
</application>
More info here.
Some users complained that LongPathsEnabled is not yet supported by Windows Explorer and other apps, although in general working alternatives can be found. For example, in this forum post an user states that
The only explorer alternative that does support long paths and long file names is total commander. It also allows to edit file names and open/process the files IF the accepting application also uses the extended API function.
Notepad seems to. MKVtoolnix too. Also, very surprisingly, MPC-HC, even though it hasnt been in development for years. Not surprisingly, sucky VLC does not (seriously?) and neither does the lovely PotPlayer.
There is also an interesting SuperUser discussion on this. In particular, this answer describes two feasible alternatives to use long paths: using Cygwin (a *nix emulation layer) or splitting the long path using NTFS Junction Points (essentially a link, like a symbolic link).
I changed all the paths to variables for Program Files and programdata (this one saves like one character, though not as important).
For something like Node.js, I changed the normal path of
C:\Program Files\nodejs\
to
%ProgramFiles%\nodejs\
This can be done with "C:\Program Files (x86)" as well using "%ProgramFiles(x86)%".
It saved me a few characters, but enough that it stopped complaining, I feel.
I found you can do it via PowerShell.
[System.Environment]::SetEnvironmentVariable("PATH", "C:\Program Files (x86......etc.....", "Machine")
So I grabbed the existing system PATH, pasted into Notepad, added my new thing, and then pasted into the "C:\Program Files" bit of the above. Path was updated. Done.
Apparently Rapid Environment Editor will do this for you (from Shital Shah's answer), but you can also shorten the paths to their 8.3 filename version. You will get a lot of mileage with just these two replacements:
C:\Program Files --> C:\PROGRA~1
C:\Program Files (x86) --> C:\PROGRA~2
If you copy your current path into Notepad, first search and replace C:\Program Files (x86) and then C:\Program Files.
Workaround:
Please restart the system. After restarting the system, PATH is no longer empty, but it may get truncated to 2047 (4095) characters
If the system restart does not help, please:
Launch C:\windows\system32\regedit.exe. Go to the registry hive "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" and clean up unnecessary directories from the “Path” key. Restart the system.
Note: In some exceptional cases if the system is not able to start, please:
Login in the safe mode
Open the command prompt shell and type:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v Path /t REG_EXPAND_SZ /d ^%SystemRoot^%\system32;^%SystemRoot^% /f
For more details:
Limitation to the length of the System PATH variable
In addition to other methods (e.g., PowerShell), I found a nice GUI, "Rapid Environment Editor" that can handle larger text values.
You can also try going through your variables to see if there are any irrelevant paths you could delete. This would free up some space for you to add another or more variables.
So I figured out the same problem I had, I noticed there were many duplicates pointing to the same location.
I removed the duplicates which can be done with the delete option when you go click the "edit Environment Varibles" button.
You could instead edit text, copy the text from there, remove duplicates using any popular apps like notepad, excel (use the delimiter as ; then remove duplicates), or use python (use .split(";"), convert into a set, ";".join(stringSet), copy into a notepad file, then replace \ with \ using the ctrl+ H ie find and replace).
I had exactly the same problem. Eventually I had to delete one of the existing variables to make the total length less than 2047.
Then I could add %MAVEN_HOME%\bin to the path variables.
Workaround: Use the Edit text button and edit your PATH in a text editor.
I found this AutoHotkey script useful, for editing or adding to my extremely long path (3743 chars now):
https://gist.github.com/roblogic/59898966f3ce594eb78a5b6147013194
(I'm not sure what the consequence of such a long path is; I may still have to fix it.)
I was going through the source code of a rainmeter skin and i could not understand :
TextShortcut1=Computer
TextShortcut2=Libraries
TextShortcut3=Internet
TextShortcut4=Media Player
TextShortcut5=Control Panel
TextShortcut6=Trash
TextShortcut7=ShutDown
TextPath1=::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
TextPath2=shell:Libraries
TextPath3=http://google.com
TextPath4=shell:MusicLibrary
TextPath5=::{21EC2020-3AEA-1069-A2DD-08002b30309d}
TextPath6=::{645FF040-5081-101B-9F08-00AA002F954E}
TextPath7=rundll32.exe user32.dll LockWorkStation
Can anyone tell me what
::{20D04FE0-3AEA-1069-A2D8-08002B30309D}
::{21EC2020-3AEA-1069-A2DD-08002b30309d}
::{645FF040-5081-101B-9F08-00AA002F954E}
these are
and also how can we get one of these for a specific location from our computer.
Those are CLSID (Windows Class Identifiers). Certain special folders within the operating system are identified by unique strings.
20D04FE0-3AEA-1069-A2D8-08002B30309D is My Computer
21EC2020-3AEA-1069-A2DD-08002b30309d is Control Panel
645FF040-5081-101B-9F08-00AA002F954E is Recycle Bin
Source:
http://www.sevenforums.com/tutorials/110919-clsid-key-list-windows-7-a.html
In response to the comment:
can i have Class Identifiers for any folder on Computer or is it just
the bunch of those.
There isn't much reason for you to add more clsids, since you can just go to other locations by typing the normal path. This is a set list that is in the registry somewhere for special folders that don't really have "paths" like C:\windows does.
what is "shell:Something" is it a cmd command or location
shell: is similar to above. It is a convenient way of accessing special folders. Here is a good site for a list: http://smallvoid.com/article/winnt-shell-keyword.html . It is more of a shortcut for Windows Explorer to access a specific location than it is a command. You cant use them in batch files as far as I know (no command line stuff).
what is %something% like %temp%
Those are environment variables. You can usually count on certain ones existing, but the user can change these. Here is a list of some more: http://en.wikipedia.org/wiki/Environment_variables#Microsoft_Windows
how do they all differ?
Well, basically, they are just different ways of accessing the same thing. Some things are more backwards compatible than others, so you have to make that choice when the time comes. If you know your app is going to be on Windows 7 and above, you can make use of some of the more convenient shell:something ones. But if it needs to run on Windows 2000, you might have to rely more on older stuff like environment variables. Environment variables can also be customized by the user.
In many of my Access (2002) programs I use the GetOpenFileNameA and GetSaveFileNameA functions from comdlg32.dll. I often set the initial directory to the user's My Documents folder (using calls to SHGetSpecialFolderLocation and SHGetPathFromIDListA from shell32). This all works fine under Windows XP.
However, I recently switched to Windows 7 as my development environment and have been getting the following error message:
You can’t open this location using
this program. Please try a different
location.
The function I use to get the My Documents location is returning the correct folder. However, even if I hard code that directory location into the GetOpenFileNameA call, I still get the error.
I came across this post: http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d but, even adapting it to work with Access instead of Excel, I had no luck.
EDIT: Suddenly this is no longer a problem for me. I suspect a windows update went out addressing this issue. Does anyone know if that's true or not?
EDIT: It turns out this is still a problem. Also, in case it helps in the troubleshooting I have found that I get this error message for any of the special folder locations (My Music, My Documents, etc). Also, if I change the location of the My Music folder to, say, C:\Test then I get this message when I try to open the folder C:\Test, while the folder C:\Users\Mike\Music (the original My Music location) opens without a hitch.
Windows 7 adds the concept of a "library", which is basically a virtual folder that includes the contents of at least two actual subdirectories. One place it uses the library is the "My Documents" folder, which (at least by default) is a library that includes both the user's documents directory ("c:\users\whoever\documents") and the public documents directory (C:\users\public\documents").
As such, the basic approach you're using simply can't work -- there is no path that denotes the Documents folder. The documents folder needs to be specified by a PIDL, not a path.
Edit: It's not clear what's going on if you can't open C:\users\user\Documents. A quick test in C++ works fine using code like:
OPENFILENAME data = {0};
wchar_t filename[256] = {0};
data.lpstrInitialDir = L"C:\\users\\jerry\\documents";
data.lStructSize = sizeof(data);
data.lpstrFile = filename;
data.nMaxFile = sizeof(filename);
GetOpenFileName(&data);
OTOH, there's no real need to specify the initial path -- the Documents folder is the default anyway.
The link I posted in my original question (http://social.msdn.microsoft.com/Forums/en-US/windowsuidevelopment/thread/3391f1dd-25b0-4102-9d5c-58309cc72c9d) held the answer after all. I'll summarize things here. To fix this behavior, you need to do away with the STRIPFOLDERBIT flag in the shell compatibility registry entry for all affected programs.
Keep in mind (and this is what tripped me up for so long) that 32-bit programs have entries in a special registry section if you have 64-bit windows. Here's the quick and dirty:
Rename STRIPFOLDERBIT to xSTRIPFOLDERBIT for the following keys (as applicable):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\excel.exe
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\ShellCompatibility\Applications\msaccess.exe
I found a thread on the Microsoft Forums where the answer tells how to set directory permissions using the LockPermission table. I tried it, but it doesn't seem to set the inheritance for any of the subdirectories. I need to be able to set the permissions for a particular folder that I create and have those permissions be inherited by all of the files and directories within and beneath it. Is there a way to do this without having to add a line in the LockPermission table for each and every directory (and file) that I want to affect?
For anyone looking to know the joys and pains of using MsiLockPermissionsEx, here is a tutorial, some best practices and a helper script. The helper script extracts SDDL from existing system resources - so you just use Regedit and Windows Explorer to set permissions and the helper script extracts them for you.
The article also discusses the challenge of supporting XP and Windows 7 permissions with a single package.
You can check it out here: http://csi-windows.com/toolkit/csigetsddlfromobject
You can either see if the MsiLockPermissionsEx support in MSI 5 handles this (and is an acceptable dependency for you as currently it's only available on Windows 7), or you can implement custom support. The LockPermissions support available in earlier versions of Windows Installer has the limitation you describe (and others).