I wanted keep my users from running "dir" in the command line, so I used DOSKEY to alias "Dir" to "CLS". The testers found out that putting a space before "DIR" will circumvent the alias.
I've tried to put a space before "DIR" when setting up the DOSKEY, but the command prompt ignores the white space.
Anyone found a way of making DOSKEY acknowledge spaces?
Thanks.
Deny your users the List Directory contents permission on all relevant locations. That's probably the easier way. That way they can run dir but it won't be of any use.
I'm not even trying to figure out why you want such a thing, though.
Regarding doskey: As you noticed, macro substituion is done literally and only at the beginning of the command line. So what do you want to do? Create macros for dir to cls with 1, 2, 3, ..., 8188 spaces before it?
Blacklisting almost never works, and it certainly isn't going to in this case. You can, for example, list the files in a directory simply by pressing TAB repeatedly.
Instead, use whitelisting. Write a console application that takes user input, checks that the input is a command that the user is allowed to run, and if so, passes that command to the shell - or, better still, implement the "approved" commands yourself, so that (a) there can't be any trickery with special characters, and (b) you can remove cmd.exe from the approved applications list - you are using software restriction policy, right?
Even if you could figure out how to make your DOSKEY macro idea work (I don't think you can), it would be pointless. Your users could easily circumvent the restriction by creating the following batch file:
#dir %*
DOSKEY macros do not work within batch files, so there is nothing to stop the batch file from executing. And your users could name the batch file anything they want, so you would have a devil of a time policing.
Related
As soon as I try to access a folder/file containing an emoji in its name from my Lua 5.2 script, for example like this:
os.execute('start "" "' .. path .. "\\scripts\\menu\\📄 My Scripts" .. '"')
The Windows' Command Prompt simply refuses to open it with the following error message:
I'm aware Windows' Command Prompt doesn't support emojis and therefore is not possible to make it work just like that, but my doubt is if won't exist some workaround or whatever I can do to ensure any Windows/Unix user is going to able to get the folder open by my Lua script without any problem.
I have tried i.e. things like use the codes instead (1246 and U+1F4F0 in this page facing up case) without success. Couldn't I for example simply use some kind of "wildcard" instead? I mean, knowing it's always going to be the very first character in the name. Or, well, any other ideas will be welcomed, cause nothing I'm trying really seems to work...
Of course if it's going to represent any problem I'll simply refuse to use them, but it came in handy for some "first sight" folder distinction and, if possible, I'd like to can count this little visual resource 🙄
This is a Problem about how the string is constructed.
I found only one solution with [[command "path"]] (on Windows 11 and Lua 5.3)...
os.execute([[start ]] .. path .. [["\scripts\menu\📄 My Scripts"]])
-- My Testpath is/was: os.execute([[dir "%localappdata%\nvim\📄 Lua"]])
...the long string ([[]]) will not be interpreted (coercionated) by Lua.
That also have the side effect that you can use single backslashs with that kind of string.
Environment variable expansion (e.g. Windows: %localappdata%) only works inside doublequotes.
Single quotes instead ([[command '%localappdate%\path\']]) will not work (expanded).
os.execute accepts only ANSI-encoded strings (win-1252 in European Windows), but it is unable to encode an emoji.
Hint: you can create .bat-file to do the task for you and invoke it from Lua with os.execute.
(This is a Windows environment by the way.)
I'm new to batch scripting and, I'll be honest, I'm struggling.
I've done a lot of googling and spent a lot of time trying to work this out but I'm not getting very far. I thought I'd throw this out to the community to see if anyone was up to the challenge. :)
First up, this is for my own personal use and curious interest to see if this is possible without writing a new .exe in a more... conventional language.
This is it : I'm using some software which is essentially portable. the only downside is that it writes to a .ini file very specific file paths which may not necessarily be correct if using another computer.
For example, if I run the software from a USB in Computer A, that computer might see the USB drive as D: and save a path in the ini as Path=D:\portables\soft1\saves\file1.xyz. But if I later use the same USB in Computer B which assigns a different letter to the drive (let's say E:) then the software will throw its toys out of the pram, because it's looking on the wrong drive for what should be now on E:. And if I run the software from a network drive or even cloud storage then the path's get even more complex.
I want to run a script that might, before running the software's .exe, look in the .ini for all instances of such filepaths and replace the full path with simply Path=.\saves\file1.xyz. The software is happy with this and can find what it needs to.
This is the ONLY thing that prevents the software being portable.
This is how I thought it would be done...
Search each line in the .ini, one at a time, to see if contains the
substring "Path="
If it finds it do the following...
a. Store the position of the character AFTER the "=" in "Path=" in a variable (let's say it's vPosA=6)
b. Search the same line for another substring "\saves\" and if it finds that then store the position of the character BEFORE the first "\" in another variable (let's say vPosB=18).
c. If vPosA and vPosB are both >0 then do the following
i. Replace all the characters on that line, from vPosA to vPosB, to "."
ii. Reset vPosA and vPosB both back to "0"
Go to the next line and repeat the process until the end of file is reached, then overwrite the .ini with the changes.
I'm looking forward to seeing what people come up with. Like I said, it's curiosity driving this. If I get no answer, or it's way way too complex I may just write the thing in VB or something and use a .bat to run it before running the software. The advantage of having it as a Batch Script is that it could shared with the software's community and the script is plain to see for all. With a compiled .exe people won't be able to see what's in it and would therefore, justifiably, distrust it.
This should do:
#echo off
setlocal enabledelayedexpansion
(for /f "tokens=*" %%a in (in.txt) do (
set "line=%%a"
if /i "!line:~0,5!"=="Path=" set "line=Path=!line:*\saves=.\saves!"
echo !line!
))>out.txt
type out.txt
Read every line, check if the first five characters are Path= (ignoring capitalization), if yes replace all from start to (including) "\saves" with ".\saves, append the string Path= in front of it. Print the line. Redirect the whole thing to another file.
You can then delete the original file and rename the new file to the old name.
NOTE: this ignores empty lines. It's possible to keep them with some more code.
So, is there a possible way to move Test.txt to C:\ProgramData\CsD2\Tools\("Unknown Folder Name")\data\per Using command prompt?
using foxidrives solution for your previous question for detecting the correct directory, then just
move test.txt "%folder%\"
Short answer: yes. Not quite sure what the situation is that has left only the middle part of your path unknown, and the need to use the comnand line, but I have encountered similar cases on Linux and expect the algoirthm can be adapted to Windows commands. It's possible to do this by hand rather than writing a shell script, but it's up to you and your skills.
Permissions matter. Make sure you elevate yours enough to read and write in Tools before continuing.
First, change directory to C:\ProgramData\CsD2\Tools\
Presumably there are many items here. Some may be "hidden," so list the contents of this directory and be sure to include an option to show hidden files and folders. If you can, restrict the search to directories only.
It's tempting to display contents recursively in the above step. It's up to you, but I find it makes the output cluttered without a script to do the rest of the work.
Now it's time to search for the subfolder set that theoretically only exists in your target folder. Suppose Tools contains the directories fldr1, fldr2, and fldr3. Use your command to list a directory's contents with the path "fldr1\data\per", then use "fldr2\data\per", and so on until it doesn't return an error. Per may be empty, but that should look different from the path not found error.
Now you've found the name of your mystery folder. Write it down for future reference.
At thus point, you know the path to Test.txt, and the full path to the destination directory. Do a move command to relocate Test.txt, and you're done. I like to relist the contents of the target directory after to be comfortable that it arrived.
When defining an environment variable (on Windows for me, maybe there is a more general guideline)
set MY_TOOL=C:\DevTools\bin\mytool.exe
if the tool is located on a path with spaces
set MY_TOOL=C:\Program Files (x86)\Foobar\bin\mytool.exe
should the environment variable already contain the necessary spaces?
That is, should it read:
set MY_TOOL="C:\Program Files (x86)\Foobar\bin\mytool.exe"
instead of the above version without spaces?
Note: In light of Joeys answer, I really should narrow this question to the examples I gave. That is, environment variables that contain one single (executable / batch) tool to be invoked by a user or by another batch script.
Maybe the spaces should be escaped differently?
I'd say, do it without quotes and use them everywhere you use the variable:
set MY_TOOL=C:\Program Files (x86)\Foobar\bin\mytool.exe
"%MY_TOOL%" -someoption someargument somefile
Especially if you let the user set the value somewhere I guess this is the safest option, since they usually tend not to surround it with quotes rather than do so.
If there are plenty of places where you use the variable you can of course redefine:
set MY_TOOL="%MY_TOOL%"
which makes things more resilient for you. Optionally you could detect whether there are quotes or not and add them if not present to be totally sure.
When your variable represents only a path to a directory and you want to append file names there, then the "no quotes" thing is even more important, otherwise you'd be building paths like
"C:\Program Files (x86)\Foobar\bin"\mytool.exe
or even:
""C:\Program Files (x86)\Foobar\bin"\my tool with spaces.exe"
which I doubt will parse correctly.
The command shell can answer your question: type C:\Pro and hit the tab key.
Autocomplete will leave all spaces as-is and add quotes around the filename. So, this is what is "officially" expected.
(this assumes that autocomplete is turned on, I'm not sure whether the default is on or off, but most people have it on anyway, I guess)
Does anyone know a pure Win32 solution for renaming a file and only changing its capitalization, that does not involve intermediate renaming to a different name or special privileges (e.g. backup, restore).
Since the Win32 subsystem generally regards two file names differing only in capitalization as the same, I haven't been able to find any solution to the problem.
A test program I made with the MoveFile API seems to work. So does the rename command in cmd.exe. What have you tried, and what error are you getting?
This isn't relevant, but further testing shows that renaming a long filename in this way works but will change the short filename (alternating between ~1 and ~2 for example), incidentally.
Just use the normal MoveFile API. That call probably just turns into ZwSetInformationFile(..., FileRenameInformation,...) The docs for FILE_RENAME_INFORMATION states that you need DELETE access and the file can't be locked etc, but those restrictions will probably apply to other solutions also.
I do not believe there is a way to expose two files with identical names that differ only in spelling to the Win32 subsystem. Even if some how you were able to create these files, the most likely result would be that only one file would be accessible - defeating the purpose of staying soley in Win32.
If you want to go into the Native layer, you can create a file with NtCreateFile and InitializeObjectAttributes w/o OBJ_CASE_INSENSITIVE or you can pad the end with extra spaces (if you pad with extra spaces, the file will not be accessible from Win32 dos paths). See here: http://www.osronline.com/ddkx/kmarch/k109_66uq.htm . I'm pretty sure you were already aware but I included it incase you did not know.
So long as your file is not immediately needed by another program, you can use my solution.
When you rename the file, capitalize, and delete the last letter. Then rename again and return the letter.
:)