I'm trying to delete some files with unicode characters in them with batch script (it's a requirement). So I run cmd and execute:
> chcp 65001
Effectively setting codepage to UTF-8. And it works:
D:\temp\1>dir
Volume in drive D has no label.
Volume Serial Number is 8C33-61BF
Directory of D:\temp\1
02.02.2010 09:31 <DIR> .
02.02.2010 09:31 <DIR> ..
02.02.2010 09:32 508 1.txt
02.02.2010 09:28 12 delete.bat
02.02.2010 09:20 95 delete.cmd
02.02.2010 09:13 <DIR> Rún
02.02.2010 09:13 <DIR> Гуцул Каліпсо
3 File(s) 615 bytes
4 Dir(s) 11 576 438 784 bytes free
D:\temp\1>rmdir Rún
D:\temp\1>dir
Volume in drive D has no label.
Volume Serial Number is 8C33-61BF
Directory of D:\temp\1
02.02.2010 09:56 <DIR> .
02.02.2010 09:56 <DIR> ..
02.02.2010 09:32 508 1.txt
02.02.2010 09:28 12 delete.bat
02.02.2010 09:20 95 delete.cmd
02.02.2010 09:13 <DIR> Гуцул Каліпсо
3 File(s) 615 bytes
3 Dir(s) 11 576 438 784 bytes free
Then I put the same rmdir commands in batch script and save it in UTF-8 encoding. But when I run nothing happens, literally nothing: not even echo works from batch script in this case. Even saving script in OEM encoding does not help.
So it seems that when I change codepage to UTF-8 in console, scripts just stop working. Does somebody know how to fix that?
If you want to have unicode supported in batch file, then CHCP on a line by itself just aborts the batch file. What I suggest is putting CHCP on each batch file line that needs unicode as follows
chcp 65001 > nul && <real command here>
Example: In my case I wanted to have a nice TAIL of my log files while debugging, but the content for even Latin-1 characters was being messed up. So here is my batch file which wraps the real tail implementation from Windows Resource Kit.
#C:\WINDOWS\system32\chcp.com 65001 >nul && tail.exe -f %1
In addition, for output to a console, you need to set a true type font, i.e. Lucidia Console.
And apparently for output to a file the command line needs to run as Unicode, so you would kick off your batch script as follows
cmd /u /c <batch file command here>
Disclaimer: Tested on Windows XP sp3 with Windows Resource Kit.
The Unicode support in console, and especially in batch files, is pretty bad.
Can you "twist" the requirement to say PowerShell or Active Scripting (VBScript or JScript)?
It will save you a lot of grief in the long run (if you need to grow this beyond this simple task)
Not to mention that both PowerShell and ActiveScripting use way more powerful languages, allowing for functions, proper loops, real variables, debuggers, a lot of goodies for a more serious project.
Try inserting a blank line as first line in your batch file...
Line 1:
Line 2:CHCP 65001
Line 3:script commmands
Should work!
Related
When using .logopen logfile.txt command, where is logfile.txt created? I managed to work around it by specifying absolute path, but am wondering when giving relative path where is file created?
For version 6.3.9600, WinDbg help says in .hh .logfile:
If you do not specify a path, the debugger uses the current directory.
For me, I installed WinDbg in the program files directory.
5:kd> .dbgdbg
0:025> |
. 0 id: 29fc attach name: C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x86\windbg.exe
Using Process Monitor, I can see that WinDbg tries to create the logfile there (and fails for permission reasons).
When I cange the working directory in the WinDbg LNK file I use for starting it, it opens the log file in that directory.
I cannot confirm #blabbs answer, since my home directory is
5: kd> !homedir
Home directory is C:\ProgramData\dbg
in both cases (running from %ProgramFiles% and running from D:\temp). If I change !homedir, the location of .logfile is not affected.
edit
the log file is created in current directory from where windbg was invoked not in homedir i always run windbg from start run (winkey +r -> windbg) and apparently it starts windbg from the installation folder and inherits the directory as well it seems
starting windbg from different folders make the logfile be created in respective current directories
>md windbglogtestone
>cd windbglogtestone
\windbglogtestone>cdb -c ".logopen mylog.txt;q" cdb
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
0:000> cdb: Reading initial command '.logopen mylog.txt;q'
Opened log file 'mylog.txt'
quit:
\windbglogtestone>cd ..
>md windbglogtestwo
>cd windbglogtestwo
\windbglogtestwo>cdb -c ".logopen mylog.txt;q" cdb
Microsoft (R) Windows Debugger Version 10.0.16299.15 X86
0:000> cdb: Reading initial command '.logopen mylog.txt;q'
Opened log file 'mylog.txt'
quit:
\windbglogtestwo>cd ..
>dir /s /b *my*.txt
\windbglogtestone\mylog.txt
\windbglogtestwo\mylog.txt
it is created in the home directory where home represents the folder where windbg is installed (normally c:\progra~\w..kits..\debug.....\x..)
see below for a windbg installation in a different path
0:000> .logopen mylogfile.txt
Opened log file 'mylogfile.txt'
0:000> !homedir
Home directory is E:\windjs\windbg_16299\x86
0:000> .shell - dir *my*
Directory of E:\windjs\windbg_16299\x86
02/14/2018 09:07 AM 0 mylogfile.txt
1 File(s) 0 bytes
0 Dir(s) 102,247,899,136 bytes free
.shell: Process exited
Press ENTER to continue
in response to lieven's comment why the hyphen in .shell command
it represents a null input file
one can pass input files to .shell for processing instead of windbg commands
using -i instead of -c
pass a single hyphen to tell there is no input file
only the shell command indicated needs to be done
I am trying to execute a SoapUI 5.2.1 test via command line with a command like this:
C:\Program Files\SmartBear\SoapUI-5.2.1\bin\testrunner.bat -s
"TestSuite 1" -c "Test001" -M -j -f "c:\auto" -r "C:\soapui-project.xml"
Apparently, this works fine.
The problem is that the execution always prints a list of all files existing in the directory from where I am running the test.
Example:
Volume in drive C is Windows
Volume Serial Number is ABC1-2BAC
Directory of C:\Users\abc\Desktop
08/06/2017 13:55 <DIR> .
08/06/2017 13:55 <DIR> ..
21/04/2017 11:57 <DIR> folder1
26/05/2017 13:00 <DIR> file2
07/10/2016 17:24 <DIR> fileN
more files and folders ...
How can I avoid that? If I execute it from "Temp" folder, a 10 seconds test takes about 10 minutes to execute because is listing tons and tons of files.
Thank you.
After days of runs and debugs I finally figured it out.
Here's the tip:
I just removed command "dir" from the end of "C:\Program Files\SmartBear\SoapUI-5.2.1\bin\testrunner.bat" file and this solves my problem. Simple as that.
Thank you anyway.
Trying to get an output through cmd with the list of folders and files inside a drive.
Some folders are written in cyrillic alphabet so I only get ??? symbols.
My command:
tree /f /a |clip
or
tree /f /a >output.txt
Result:
\---???????????
\---2017 - ????? ??????? ????
01. ?????.mp3
02. ? ???????.mp3
03. ????.mp3
04. ?????? ? ???.mp3
05. ?????.mp3
06. ???? ?????.mp3
07. ???????? ????.mp3
08. ??? ?? ?????.mp3
Cover.jpg
Any idea?
tree.com uses the native UTF-16 encoding when writing to the console, just like cmd.exe and powershell.exe. So at first you'd expect redirecting the output to a file or pipe to also use Unicode. But tree.com, like most command-line utilities, encodes output to a pipe or disk file using a legacy codepage. (Speaking of legacy, the ".com" in the filename here is historical. In 64-bit Windows it's a regular 64-bit executable, not 16-bit DOS code.)
When writing to a pipe or disk file, some programs hard code the system ANSI codepage (e.g. 1252 in Western Europe) or OEM codepage (e.g. 850 in Western Europe), while some use the console's current output codepage (if attached to a console), which defaults to OEM. The latter would be great because you can change the console's output codepage to UTF-8 via chcp.com 65001. Unfortunately tree.com uses the OEM codepage, with no option to use anything else.
cmd.exe, on the other hand, at least provides a /u option to output its built-in commands as UTF-16. So, if you don't really need tree-formatted output, you could simply use cmd's dir command. For example:
cmd /u /c "dir /s /b" | clip
If you do need tree-formatted output, one workaround would be to read the output from tree.com directly from a console screen buffer, which can be done relatively easily for up to 9,999 lines. But that's not generally practical.
Otherwise PowerShell is probably your best option. For example, you could modify the Show-Tree script to output files in addition to directories.
I am using Jboss 4.0.2 in Solaris to run a webapp.
JBoss is configured to use the factory default log4j.xml file, and this has a ConsoleAppender. I am redirecting stdout of jboss java process to a file.
Something interesting happens when I try to cleanup this file - jboss.out.
This is where I start.
$ ls -alhrt jboss.out
-rw-r--r-- 1 ipunity ipunity 458M Jan 8 07:22 jboss.out
Then I clean up this file. Jboss is still running.
$ >jboss.out
$ ls -alhrt jboss.out
-rw-r--r-- 1 ipunity ipunity 0 Jan 8 07:24 jboss.out
Now if go click on a link in my webapp, it starts logging, but the whole file kind of reappears again!
$ ls -alhrt jboss.out
-rw-r--r-- 1 ipunity ipunity 458M Jan 8 07:25 jboss.out
Any ideas on whats going on?
Is ConsoleAppender buffering the data? I dont have enough memory to hold 458MB and my disk swap is almost unused. I dont see any temp file this huge either.
This is probably a sparse file, created by the OS when JBoss issues a write with the file pointer set to +[whatever the old size of the file was].
Check the disk space actually used by the new file -- on most unices, du -k jboss.out should work. If the file is sparse, you should see something significantly less than the size shown by ls.
Generally, removing log files while they're being written to is tricky. To avoid that issue when capturing stdout, I tend to pipe stdout to a program like cronolog or rotatelogs instead of straight to a file.
How can I write to parallel port through Windows XP command line?
Looking at your reply to Zoredache, your real problem is not output to the parallel port, that's trivial.
Your real problem is how to get a 0xff character on stdout. This is possible with a trivial .com executable which invokes the relevant soft interrupt, but to be honest it's probably easier to create a file with that single 0xff character in it and then just copy that to the printer:
> copy /b data.bin lpt1
Note the /b flag which tells copy that the file is a binary file.
Back in the DOS days we would frequently use a command like type filename.txt > lpt1 to print our text files.