I'm trying to make a script that hides some icons on desktop. When I run it line by line in command promt it works, but when I run the *.bat file in cmd it says "attributesi was unexpected at this time."
Here is the code:
set address=file.ext
set attributes=attrib %address%
for /F "tokens=*" %i in ("%attributes%") do set var=%i
set var=%var: =%
if %var:~1,1%==H (attrib -H %address%)else (attrib +H %address%)
Try this:
for /F "tokens=*" %%i in ("%attributes%") do set var=%%i
The for loop variables need %% instead of % when run in a batch file. But from the command line, % works just fine.
If you need any additional help with batch files, you should check out Rob van der Woude's pages on batch file scripting. It's a very rich resource on a language that's becoming increasingly difficult to find information on.
Speaking of which, I feel compelled to mention that Powershell scripting has largely replaced DOS batch file scripting (and for good reason). Almost anything you can do in a DOS batch file, you can now do easier in a Powershell script. Definitely worth checking into if you plan on doing more Windows-based scripting.
Hidedesktopicons.exe wasn't doing anything for me, but link that is given actually works. http://www.actualtools.com/forum/read.php?FID=8&TID=1072
Related
So I have a series of thousands of .zip files that need to be opened.
They are password protected, but I have the passwords.
Trying to automate the opening of these. the deflate64 issue is causing a lot of pain.
Okay, So deflate64 is proprietary which is annoying as that stops you from using the normal zipfile library in python. As a workaround i typically make a subprocess call to 7zip or similar. So something like:
import subprocess, sys
subprocess.Popen(["7z", "e", f"{filename}", f"-o{destination}", "-y" "-p" password])
Then naturally just run that in a loop over your files. Depending on how they are laid out you might want to just glob everything in a directory or pipe them via stdin etc.
Often tasks like this are well suited to shell scripts so you might want to consider that, I'm not a windows user but i think something like the following script would work as well:
#echo off
set pass=[password]
set folder=[folder]
for /R "%folder%" %%I in ("*.zip") do (
"C:\somedirectory\7z.exe" x -p%pass% -y -o"%%~dpI" "%%~fI"
)
my scenario is: I'm using vim to open some .cpp files, for example
vim 1.cpp src/2.cpp root/src/3.cpp
Sometimes, I wish to rebuild 3.cpp so I have to use another window to
"rm root/src/3.o"
and inside vim, type
":make"
This works fine, NP. But I am looking for a .vimrc function/command that:
When I switch to buffer, e.g. "root/src/3.cpp" and press this command, vim will detect the directory of "root/src" and the file name without suffix "3", and automatically execute a command of "rm root/src/3.o".
In this case, I can casually switch to any buffer and re-trigger the build of this very file.
Note I don't wish to map gmake tool command like "make clean" because we use several different make utilities like scons, cmake, etc.
So how to write this function/command in .vimrc? Thanks.
:call system('rm '.expand('%:p:r')) as #Kent said, or even simply :!rm %:p:r.
But I'm quite surprised you need to do that. Tools in charge of compilation chains usually understand dependencies (which ever the tool is), and you shouldn't need to remove the object file that often to need a mapping to do it for you.
PS: it's perfectly possible (but I need to update the doc) to support CMake, or out-of-source compilation from vim. But indeed, with out-of-sources compilation, you wouldn't need to delete those files manually, a :make clean if :make already works.
you can get root/src/3 from root/src/3.cpp buffer by:
expand('%:p:r')
Then you are free to concatenate the .o to end, and build the command.
I am trying to convert a PDF document into a PNG file using ImageMagick command line tools from a ASP.NET website. I create a new shell process and ahve it execute the following command:
convert -density 96x96 "[FileNameAndPath].pdf" "[FileNameAndPath].png"
This runs well when testing the website on my local machine with the ASP.NET Develeopment Server of VS and the command also works well when manually entered into the shell. When running from the programatically created shell in ASP.NET there is the following error message:
Invalid Parameter - 96x96
Does anybody know why that happens and what to do?
I have tested the command while being logged in on the server via RDP with a different user account than the ASP.NET process. I have used exactly the same ImageMagick and Ghostscript installation files as on my local machine and have activated adding the ImageMagick installation path to the enironment variables during installing. The server has not been rebooted since than.
convert is also the name of a windows executable which converts FAT filesystem to NTFS. When you do not specify the full path of an executable, quote:
...the system first searches the current working directory and then
searches the path environment variable, examining each
directory from left to right, looking for an executable filename that
matches the command name given.
"C:\Windows\System32" is generally present in the beginning of %PATH% variable, causing the Windows convert utility to launch, which fails with "Invalid Parameter" error as expected.
Try specifying the full path of the ImageMagick's convert.exe like so:
"C:\Program Files\ImageMagick\convert.exe" -density 96x96 "path_and_filename.pdf" "path_and_filename.png"
As others have stated convert points to a different program in your PATH. Instead preface your command with magick. So your command would instead be:
magick convert -density 96x96 "[FileNameAndPath].pdf" "[FileNameAndPath].png"
In Window actually exists a "convert.exe" in system32 - make sure your script doesn't start that one (maybe the environment paths on your development machine are set differently).
I am only answering this late because imagemagick was updated. Now, if you wish to use the "convert" command, you do it like this:
magick convert "image.png" "document.pdf"
or
magick convert "image_00*.png" "document.pdf"
for multiple images.
Same syntax for command, just add magick before it
A couple more options for fixing this:
Edit your Path system variable to contain the path to imagemagick
as it's first content and then add the rest after it. This will make
windows always find the imagemagic convert first before it finds
the other convert program. So something like this: C:\Program Files\ImageMagick-6.9.2-Q16;C:\Program Files\Haskell Platform\2014.2.0.0\lib\extralibs\bin;...
Another option is to create a dedicated folder somewhere on your machine where you will place shortcuts for some of these name clashes. Then what you do is that you rename those shortcuts to meaningful names, for example convert_image_magick, then add the path to this folder to your system path. So now as you hit tab more, you will finally find the right program you want to run
yes! if you launch an Administrator command window it defaults to C:\windows\sytem32\ ... as long as you're not in that directory the command will pickup the ImageMagick convert.exe
My issue was I was using the "FORFILES" command which is tricky because it requires using
"cmd /c" and passing the convert command with #path and #file parameters and it does some escaping of slashes... needless to say it's caused me hours and hours of headache. It even parses hex characters, like if your filepath has the combination 0x00 in it, it will think that's a hex value and mangle your path. I had a filepath named C:\ImageRes3000x3000
and FORFILES interprets that literally and it caused a strange path issue. Sorry if this is a long useless post but it's meant to be FYI, if someone runs across this, maybe it will help them. That being said, FORFILES and "convert.exe" are a powerful and simple image renaming line script combo.
here's my full 3 line image renaming script
robocopy D:\SRC_DIR\ D:\DEST_DIR\_staging *.jpg /e /MAXAGE:2
FORFILES /P D:\DEST_DIR\_staging\ /S /M *.jpg /C "cmd /c convert.exe #path -quality 65 -resize 1500 D:\RESIZED_DIR\\#file"
DEL D:\DEST_DIR\_staging\*.* /S /Q
Whenever I start a shell in vim using :sh, it doesn't source my ~/.bashrc file. How can I get it to do this automatically?
See :help 'shell'. You can set this string to include -l or --login, which will source your .bashrc file. So, you might have a line like this in your .vimrc:
set shell=bash\ --login
Note that this will alter everything that invokes the shell, including :!. This shouldn't be much of a problem, but you should be aware of it.
The value of this command can also be changed by setting the $SHELL environment variable.
If it doesn't source your .bashrc file, it may still source your .bash_profile file. I usually make one of them a symlink to the other. If your .bashrc performs some particularly odd one-time operations, you may have to edit it to only perform those operations with a login shell, but I've never had problems with it.
~/.vimrc
cmap sh<CR> !bash --login<CR>
If you quickly enter "sh<Enter>" in command-line, you can start bash with sourcing ~/.bashrc. So dirty.
At a unix command line, what's the difference between executing a program by simply typing it's name, vs. executing a program by typing a . (dot) followed by the program name? e.g.:
runme
vs.
. runme
. name sources the file called name into the current shell. So if a file contains this
A=hello
Then if you sources that, afterwards you can refer to a variable called A which will contain hello. But if you execute the file (given proper execution rights and #!/interpreterline), then such things won't work, since the variable and other things that script sets will only affects its subshell it is run in.
Sourcing a binary file will not make any sense: Shell wouldn't know how to interpret the binary stuff (remember it inserts the things appearing in that file into the current shell - much like the good old #include <file> mechanism in C). Example:
head -c 10 /dev/urandom > foo.sh; . foo.sh # don't do this at home!
bash: �ǻD$�/�: file or directory not found
Executing a binary file, however, does make a lot of sense, of course. So normally you want to just name the file you want to execute, and in special cases, like the A=hello case above, you want to source a file.
Using "source" or "." causes the commands to run in the current process. Running the script as an executable gives it its own process.
This matters most if you are trying to set environment variable in current shell (which you can't do in a separate process) or want to abort the script without aborting your shell (which you can only do in a separate process).
The first executes the command. The second is shorthand for including a shell script inside another.
This syntax is used to "load" and parse a script. It's most useful when you have a script that has common functionality to a bunch of other scripts, and you can just "dot include" it. See http://tldp.org/LDP/abs/html/internal.html for details (scroll down to the "dot" command).
Running "runme" will create a new process which will go on its merry little way and not affect your shell.
Running ". runme" will allow the script "runme" to change your environment variables, change directories, and all sorts of other things that you might want it to do for you. It can only do this because it's being interpreted by the shell process that's already running for you. As a consequence, if you're running bash as your login shell, you can only use the "." notation with a bash script, not (for example) a binary on C shell script.