One bug in SED.EXE and another in MS-DOS cmd.exe DEL command

That was a fun day, a WTF one (What's The Fun?!). Wasted at least an hour on troubleshooting third party applications... -_-'

Damn'.

Sed.exe temporary file bug

The utility 'sed.exe' (from GnuWin32) helped me in modifying a file during a headless installation process (changing a property in a "web.config" file). Until there, it was fairly cool.


But here comes the less fun part, I noticed that the executable creates a temporary file right in the middle of its working directory. This is a bug listed and commented here:

http://sourceforge.net/p/gnuwin32/bugs/477/.

From what it looks like, the tool may have regressed in Windows 7 again. Unless it's because of the 64 bit system and the WoW emulation...? Anyway.

The temporary file is not that random, first we know where it is located, second, its name is made of 3 known characters 'sed' and 6 random alphanumeric ones. In regular expressions it would be something like

/sed[a-zA-Z0-9]{6}/

So let's rock'n'roll with a workaround. Let's call:

$> DEL /q sed??????

Let's call it in a directory that contains a file sedE1, a file sedE1f8fd, and a file sedE1f8fdBIS. What happens. All three are deleted. WTF?!

Wildcards issue

After further investigations, "sed????" works fine. So what is wrong?

It seems that, as far as wildcards are concerned:

"?????????" <=> "*"

The explanation I found is that DEL works still on the 8.3 character file name model.

So finally the only workaround is to wrap sed.exe into a batch file:

Launch TightVNC using the Computer Name - or - How to Get IP from Computer Name in MS-DOS cmd.exe batch file

First, knowing the name of a computer, we want to get its IP. The script 'GetIpFromName' does that..

Second, we need to call `StartVncViewer MyServerName` to start VncViewer..

See scripts below:

Work around AutoIT stdin limitation

The fastest way to implement a small script and to process a file (or a chunk of data) is to use the standard input rather than file-handles.

1/ It is easier to redirect a file instead of providing parameters to a program.

2/ When you use redirections, the operating system works for you: it opens the file and feeds the program with its content.

C:\> AutoIt3.exe DiffPrettyfier.au3 < MyInput.txt > MyOutput.txt

The content of the script is straight forward:

$myInput = ConsoleRead()

; do something here

; (...)

ConsoleWrite($myOutput)

But there is one problem that makes this a bit harder: AutoIT 'ConsoleRead' doesn't handle input bigger than '65535' characters. So here is a little workaround: use the function 'StdinRead' below instead of 'ConsoleRead':

;-----------------------------------------------------------------

; Name .........: StdinRead

; Description ..: Wrapper for ConsoleRead because it doesn't

; handle big files

; Warning ......: This is a workaround but it has limitations too,

; I used a big file to test this function but it

; might fail on a VERY big file (eg. if the file

; contains 2 147 483 647 characters)

; original big file tested: 18 030 950

; biggest string size allowed: 2 147 483 647

; Parameters ...: n/a

; Return .......: String read on STDIN or empty String "" if

; nothing found on STDIN

;-----------------------------------------------------------------

Func StdinRead()

Const $MAX_BUFFER = 65535

$eofReached = False

$fileContent = ""

While Not $eofReached

$buffer = ConsoleRead($MAX_BUFFER)

If @error Or $buffer = "" Then $eofReached = True

$fileContent &= $buffer

WEnd

Return $fileContent

EndFunc ;==>StdinRead

NOTE: For "ConsoleWrite" to work as expected (redirecting output to stdout), you need to compile the script using the "/console" switch.

Convert '%date%' into format 'yyyy-mm-dd'

The format returned by '%date%' is different between Windows 2000 (eg. 'Mon 16/06/2008') and Windows XP (eg. '16/06/2008').

The snippet below works on Windows XP:

%date:~6,4%-%date:~3,2%-%date:~0,2%

but this one works on Windows 2000 too:

%date:~-4,4%-%date:~-7,2%-%date:~-10,2%