Hi Dar,
Yes, this is a viable work-around for the Windows shell bug.
function newShell pCommand
local tResult
set the hideConsoleWindows to true
set the shellCommand to "cmd.exe /u" --/U for UTF16 output
put shell(pCommand) into tResult
if the result is empty then -- no errors
put textDecode(tFileDetails,"UTF-16") into tResult
replace cr&cr with cr in tResult
end if
return tResult
end newShell
The above can be used with any Windows shell command that is expected to
return non-ASCII text
Thank you, I was unaware of the /U switch for CMD.EXE.
Still, I would like the "detailed files" bug fixed by LiveCode as the
only way under Windows (that I have found) to get the equivalent data
appears to be with the "wmic" command and that requires asking for file
attributes one file at a time, which means multiple shell calls and that
slows my work-around down a lot.
Example:
wmic datafile where Name="C:\\Users\\paul\\Desktop\\Unicode
Study\\peace.docx" get Name,FileSize,CreationDate,LastModified,LastAccessed
Sorry for not responding sooner.
On 8/23/2019 9:48 AM, dsc--- via use-livecode wrote:
Paul, does this solve the problem with shell() on Windows?
On Aug 22, 2019, at 10:27 PM, dsc--- via use-livecode
<use-livecode@lists.runrev.com> wrote:
I tried it.
on mouseUp
set the shellCommand to "cmd.exe /u"
put textDecode( shell("dir"), "UTF-16" )
end mouseUp
That does seem to double up the newlines. It looks like it works otherwise.
Dar
On Aug 22, 2019, at 12:15 PM, dsc--- via use-livecode
<use-livecode@lists.runrev.com> wrote:
The shellCommand property for Windows is "cmd.exe", not "command.com
<http://command.com/>" as described in the dictionary.
I wonder how setting that to "cmd.exe /u" would affect this behavior.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
