info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
How to deal with "new Date()" error when running JScript in Windows Script Host ?
78 views
Skip to first unread message
Dr J R Stockton
Mar 12, 2018, 2:26:33 PM3/12/18
to
At present, the second Sunday of March having started, when running
JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
D = new Date() thinks that it is tomorrow already, which upsets my
"show today's files" logic. The reason is that WSH believes that the
UK uses the US DST clock rules. I expect the fault to go away on
the last Sunday of March, and to reappear for a week from the last
Sunday of October, etc.
I believe that the same root error will occur in other places using
EU Summer Time Rules - and it could occur elsewhere.
So I want to fix the root problem by using, instead of "new Date()"
a new function "NewDate()" which will get the date from the MS-DOS
environment variable %date% or by executing the MS-DOS DIR command.
Does anyone here know how to write that new function (and, if so,
please demonstrate)? I have reason to think that it can be done
using non-ECMA calls within WSH.
--
(c) John Stockton, near London, UK. Using Google Groups. |
Mail: J.R.""""""""@physics.org - or as Reply-To, if any. |
JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
D = new Date() thinks that it is tomorrow already, which upsets my
"show today's files" logic. The reason is that WSH believes that the
UK uses the US DST clock rules. I expect the fault to go away on
the last Sunday of March, and to reappear for a week from the last
Sunday of October, etc.
I believe that the same root error will occur in other places using
EU Summer Time Rules - and it could occur elsewhere.
So I want to fix the root problem by using, instead of "new Date()"
a new function "NewDate()" which will get the date from the MS-DOS
environment variable %date% or by executing the MS-DOS DIR command.
Does anyone here know how to write that new function (and, if so,
please demonstrate)? I have reason to think that it can be done
using non-ECMA calls within WSH.
--
(c) John Stockton, near London, UK. Using Google Groups. |
Mail: J.R.""""""""@physics.org - or as Reply-To, if any. |
Jon Ribbens
Mar 12, 2018, 3:01:42 PM3/12/18
to
On 2018-03-12, Dr J R Stockton <J.R.St...@physics.org> wrote:
> At present, the second Sunday of March having started, when running
> JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> D = new Date() thinks that it is tomorrow already, which upsets my
> "show today's files" logic. The reason is that WSH believes that the
> UK uses the US DST clock rules. I expect the fault to go away on
> the last Sunday of March, and to reappear for a week from the last
> Sunday of October, etc.
>
> I believe that the same root error will occur in other places using
> EU Summer Time Rules - and it could occur elsewhere.
>
> So I want to fix the root problem by using, instead of "new Date()"
> a new function "NewDate()" which will get the date from the MS-DOS
> environment variable %date% or by executing the MS-DOS DIR command.
>
> Does anyone here know how to write that new function (and, if so,
> please demonstrate)? I have reason to think that it can be done
> using non-ECMA calls within WSH.
This seems to work for me:
> At present, the second Sunday of March having started, when running
> JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> D = new Date() thinks that it is tomorrow already, which upsets my
> "show today's files" logic. The reason is that WSH believes that the
> UK uses the US DST clock rules. I expect the fault to go away on
> the last Sunday of March, and to reappear for a week from the last
> Sunday of October, etc.
>
> I believe that the same root error will occur in other places using
> EU Summer Time Rules - and it could occur elsewhere.
>
> So I want to fix the root problem by using, instead of "new Date()"
> a new function "NewDate()" which will get the date from the MS-DOS
> environment variable %date% or by executing the MS-DOS DIR command.
>
> Does anyone here know how to write that new function (and, if so,
> please demonstrate)? I have reason to think that it can be done
> using non-ECMA calls within WSH.
var WshShell = new ActiveXObject('WScript.Shell')
var aDate = WshShell.Exec('cmd /c echo %date%').StdOut.ReadLine().split('/')
var dDate = new Date(aDate[2], aDate[1] - 1, aDate[0])
Mind you, just 'new Date()' seems to be working for me anyway.
Dr J R Stockton
Mar 12, 2018, 7:01:30 PM3/12/18
to
On Monday, March 12, 2018 at 7:01:42 PM UTC, Jon Ribbens wrote:
Well, you've not said where you are, though I think you are UK.
Looking at the date alone, the code can only be properly tested
after 23:00 try just 'new Date()' then ...
Your code does do what you think, and I thought, was wanted ...
but your Windows is set to use date field order D/M/Y, whereas
I always follow ISO 8601 and use YYYY-MM-DD. I have easily enough
changed the code to accept any likely delimiter, and I now
distinguish Y M D and D M Y by the size of the Y field. But
I'd prefer it to work on any reasonable PC, and I fear my Mexican
neighbour might use M D Y.
I now recall another way of getting the date/time from Windows at
a Prompt
... ...
MS-DOS Prompt> wmic OS Get localdatetime /value
LocalDateTime=20180312214139.165000+000
and in WSH
var Line = WWshShell.Exec('cmd /c wmic OS Get localdatetime /value | find "Local"').StdOut.ReadLine()
LocalDateTime=20180312214947.234000+000
which I can easily enough process to the required form when
I find out what that really is. I think I've done that; but I'll
sleep on it before testing fully.
Thanks for including the key help in your answer!
H'mmm - there should be an API for using WMIC directly from JScript?
Looking at the date alone, the code can only be properly tested
after 23:00 try just 'new Date()' then ...
Your code does do what you think, and I thought, was wanted ...
but your Windows is set to use date field order D/M/Y, whereas
I always follow ISO 8601 and use YYYY-MM-DD. I have easily enough
changed the code to accept any likely delimiter, and I now
distinguish Y M D and D M Y by the size of the Y field. But
I'd prefer it to work on any reasonable PC, and I fear my Mexican
neighbour might use M D Y.
I now recall another way of getting the date/time from Windows at
a Prompt
... ...
MS-DOS Prompt> wmic OS Get localdatetime /value
LocalDateTime=20180312214139.165000+000
and in WSH
var Line = WWshShell.Exec('cmd /c wmic OS Get localdatetime /value | find "Local"').StdOut.ReadLine()
LocalDateTime=20180312214947.234000+000
which I can easily enough process to the required form when
I find out what that really is. I think I've done that; but I'll
sleep on it before testing fully.
Thanks for including the key help in your answer!
H'mmm - there should be an API for using WMIC directly from JScript?
Jon Ribbens
Mar 13, 2018, 8:06:31 AM3/13/18
to
On 2018-03-12, Dr J R Stockton <J.R.St...@physics.org> wrote:
> H'mmm - there should be an API for using WMIC directly from JScript?
Something like this perhaps:
> H'mmm - there should be an API for using WMIC directly from JScript?
var oWMI = GetObject('winmgmts:')
var eOSes = new Enumerator(oWMI.InstancesOf('Win32_OperatingSystem'))
var oOS
while (!(oOS && oOS.Primary) && !eOSes.atEnd()) {
oOS = eOSes.item()
eOSes.moveNext()
}
var oDate = new ActiveXObject('WbemScripting.SWbemDateTime')
oDate.Value = oOS.LocalDateTime
WScript.Echo(oDate.Day + '/' + oDate.Month + '/' + oDate.Year)
I'm not sure if bothering to search the operating system list is
overkill or if just
var oOS = new Enumerator(oWMI.InstancesOf('Win32_OperatingSystem')).item()
would be sufficient but presumably it doesn't hurt.
Michael Haufe (TNO)
Mar 13, 2018, 4:19:42 PM3/13/18
to
Dr J R Stockton wrote:
> H'mmm - there should be an API for using WMIC directly from JScript?
<script>
> H'mmm - there should be an API for using WMIC directly from JScript?
var wmi = GetObject("WINMGMTS:\\\\.\\ROOT\\cimv2:Win32_OperatingSystem=@")
WScript.Echo(wmi.LocalDateTime)
</script>
Dr J R Stockton
Mar 14, 2018, 4:29:55 PM3/14/18
to
If course, it is not sufficient that the code chosen does
NOT apply US DST rules; it is also important that it DOES
apply the correct local Summer Time rules - I'll have to
wait another ten days or so to verify that. The present
replacement for new Date() follows ...
function NewDate() { var WMIC, LDT, M // c. 2018-03-13
// Use for 'new Date()' as in UK WSH JS uses USA DST rules :-(
/// M = 'cmd /c wmic OS Get localdatetime /value | find "Local"'
/// WMIC = WshShell.Exec(M).StdOut.ReadLine()
/// After Jon Ribbens in CLJ
/// Michael Haufe wrote in CLJ :-
/// var wmi = GetObject("WINMGMTS:\\\\.\\ROOT\\cimv2:Win32_OperatingSystem=@")
/// WScript.Echo("##### New: " + wmi.LocalDateTime) // JRS textmod
/// so
M = "WINMGMTS:\\\\.\\ROOT\\cimv2:Win32_OperatingSystem=@"
WMIC = GetObject(M).LocalDateTime // After Michael Haufe in CLJ
// WScript.Echo(" :: WMIC = " + WMIC)
M = WMIC.match(/(\d\d\d\d)(\d\d)(\d\d)(\d\d)(\d\d)(\d\d)\.(\d\d\d)/)
// WScript.Echo(" :: M = " + M)
LDT = new Date(M[1], M[2]-1, M[3], M[4], M[5], M[6], M[7])
// WScript.Echo(" :: LDT = " + LDT)
return LDT } // Local DateTime Object from WMIC
Julio Di Egidio
Mar 14, 2018, 5:18:19 PM3/14/18
to
On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
> At present, the second Sunday of March having started, when running
> JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> D = new Date() thinks that it is tomorrow already, which upsets my
> "show today's files" logic.
Can you show code that reproduces the problem?
> At present, the second Sunday of March having started, when running
> JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> D = new Date() thinks that it is tomorrow already, which upsets my
> "show today's files" logic.
> The reason is that WSH believes that the
> UK uses the US DST clock rules. I expect the fault to go away on
> the last Sunday of March, and to reappear for a week from the last
> Sunday of October, etc.
Julio
Dr J R Stockton
Mar 15, 2018, 5:19:11 AM3/15/18
to
On Wednesday, March 14, 2018 at 9:18:19 PM UTC, Julio Di Egidio wrote:
> On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
>
> > At present, the second Sunday of March having started, when running
> > JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> > D = new Date() thinks that it is tomorrow already, which upsets my
> > "show today's files" logic.
>
> Can you show code that reproduces the problem?
Yes.
> On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
>
> > At present, the second Sunday of March having started, when running
> > JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> > D = new Date() thinks that it is tomorrow already, which upsets my
> > "show today's files" logic.
>
> Can you show code that reproduces the problem?
> > The reason is that WSH believes that the
> > UK uses the US DST clock rules. I expect the fault to go away on
> > the last Sunday of March, and to reappear for a week from the last
> > Sunday of October, etc.
>
> It's hardly possible that such a "feature" would have gone unnoticed.
Prompt>type jscptbug.js
// This tests JScript clock change dates; errors in Win 7 & 10
// Run in WSH at command line with Prompt>cscript //nologo jscptbug.js
// For a browser, remove use of WScript object and use alert(Out)
var IzzDat, IzzOff, WozDat, WozOff = NaN, J, Out = []
Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
Out.push(
"\n Your " + WScript.Name + " is version " + WScript.version +
"\n Your Script Engine is " + ScriptEngine() + " " +
ScriptEngineMajorVersion() + "." +
ScriptEngineMinorVersion() + "." + ScriptEngineBuildVersion() )
IzzDat = new Date()
Out.push(" They say :\n LCT = " + IzzDat.toString() +
"\n GMT = " + IzzDat.toUTCString())
Out.push(
" The following shows roughly when your civil clock offset\n" +
" changes over four years, according to your Script Engine.")
function Pad5(N) { var S = String(N)
while (S.length < 5) S = " " + S ; return S }
for (J = 0 ; J < 1475 ; J++) {
IzzDat = new Date(2017, 0, J) ; IzzOff = IzzDat.getTimezoneOffset()
if (J > 0 && IzzOff != WozOff) {
Out.push("")
Out.push(Pad5(WozOff) + " " + WozDat)
Out.push(Pad5(IzzOff) + " " + IzzDat)
}
WozOff = IzzOff ; WozDat = IzzDat
}
Out = Out.join("\n") + "\n -----"
// alert(Out)
WScript.StdOut.WriteLine(Out)
// End
Prompt>
Dr J R Stockton
Mar 15, 2018, 5:35:27 AM3/15/18
to
On Thursday, March 15, 2018 at 9:19:11 AM UTC, Dr J R Stockton wrote:
> On Wednesday, March 14, 2018 at 9:18:19 PM UTC, Julio Di Egidio wrote:
> > On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
> >
> > > At present, the second Sunday of March having started, when running
> > > JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> > > D = new Date() thinks that it is tomorrow already, which upsets my
> > > "show today's files" logic.
> ...
> On Wednesday, March 14, 2018 at 9:18:19 PM UTC, Julio Di Egidio wrote:
> > On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
> >
> > > At present, the second Sunday of March having started, when running
> > > JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> > > D = new Date() thinks that it is tomorrow already, which upsets my
> > > "show today's files" logic.
P.S. Slightly similar code in VBS shows me correct change dates but incorrect Autumn change times.
Jon Ribbens
Mar 15, 2018, 7:39:03 AM3/15/18
to
On 2018-03-15, Dr J R Stockton <J.R.St...@physics.org> wrote:
> Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
That gives me:
> Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
JSCPTBUG.JS (c) J R Stockton 2018-01-29+
Your Windows Script Host is version 5.812
Your Script Engine is JScript 5.8.16384
They say :
LCT = Thu Mar 15 11:36:45 UTC 2018
GMT = Thu, 15 Mar 2018 11:36:45 UTC
The following shows roughly when your civil clock offset
changes over four years, according to your Script Engine.
0 Sun Mar 26 00:00:00 UTC 2017
-60 Mon Mar 27 00:00:00 UTC+0100 2017
-60 Sun Oct 29 00:00:00 UTC+0100 2017
0 Mon Oct 30 00:00:00 UTC 2017
0 Sun Mar 25 00:00:00 UTC 2018
-60 Mon Mar 26 00:00:00 UTC+0100 2018
-60 Sun Oct 28 00:00:00 UTC+0100 2018
0 Mon Oct 29 00:00:00 UTC 2018
0 Sun Mar 31 00:00:00 UTC 2019
-60 Mon Apr 1 00:00:00 UTC+0100 2019
-60 Sun Oct 27 00:00:00 UTC+0100 2019
0 Mon Oct 28 00:00:00 UTC 2019
0 Sun Mar 29 00:00:00 UTC 2020
-60 Mon Mar 30 00:00:00 UTC+0100 2020
-60 Sun Oct 25 00:00:00 UTC+0100 2020
0 Mon Oct 26 00:00:00 UTC 2020
-----
Julio Di Egidio
Mar 15, 2018, 1:50:21 PM3/15/18
to
On Thursday, 15 March 2018 10:19:11 UTC+1, Dr J R Stockton wrote:
> On Wednesday, March 14, 2018 at 9:18:19 PM UTC, Julio Di Egidio wrote:
> > On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
> >
> > > At present, the second Sunday of March having started, when running
> > > JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> > > D = new Date() thinks that it is tomorrow already, which upsets my
> > > "show today's files" logic.
> >
> > Can you show code that reproduces the problem?
>
> Yes.
I don't see any bug there. How do you go from that code to there is a bug
> On Wednesday, March 14, 2018 at 9:18:19 PM UTC, Julio Di Egidio wrote:
> > On Monday, 12 March 2018 19:26:33 UTC+1, Dr J R Stockton wrote:
> >
> > > At present, the second Sunday of March having started, when running
> > > JScript in Windows (7 & 10) Script Host in the UK after 23:00 LCT,
> > > D = new Date() thinks that it is tomorrow already, which upsets my
> > > "show today's files" logic.
> >
> > Can you show code that reproduces the problem?
>
> Yes.
in the WSH JScript implementation?
> > > The reason is that WSH believes that the
> > > UK uses the US DST clock rules. I expect the fault to go away on
> > > the last Sunday of March, and to reappear for a week from the last
> > > Sunday of October, etc.
> >
> > It's hardly possible that such a "feature" would have gone unnoticed.
>
> Never underestimate the chronological ineptitude of programmers on the
> wrong side of the Pacific Ocean.
noticed it: in fact, on the contrary, there are hordes of people ready to
jump on a Microsoft bug, historically; and, 2) 95% of the disasters across
the software industry are due to mis*management*, and the fact that those
turds do not even ask before messing things up irreparably... Indeed, rather
realise that it's thanks to engineers and technicians of various sorts that
this planet has not yet (fully) sunk under the weight of its own bullshit and
bullshitting... Just to say.
Julio
Dr J R Stockton
Mar 15, 2018, 4:37:22 PM3/15/18
to
On Thursday, March 15, 2018 at 11:39:03 AM UTC, Jon Ribbens wrote:
On what system?
I got, at 20:08 UK time today, in Windows 7 (and similar in
Windows 10), alleging that it is Summer Time. But Win7
wants to update, which I don't want it to do this evening
(Win10 does not want to update yet, but I've only just
turned that PC on).
Your Windows Script Host is version 5.8
Your Script Engine is JScript 5.8.18921
They say :
LCT = Thu Mar 15 21:08:04 UTC+0100 2018
GMT = Thu, 15 Mar 2018 20:08:04 UTC
> On 2018-03-15, Dr J R Stockton <see sig> wrote:
> > Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
>
> That gives me:
>
> JSCPTBUG.JS (c) J R Stockton 2018-01-29+
>
> Your Windows Script Host is version 5.812
> Your Script Engine is JScript 5.8.16384
> They say :
> LCT = Thu Mar 15 11:36:45 UTC 2018
> GMT = Thu, 15 Mar 2018 11:36:45 UTC
> ...
> > Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
>
> That gives me:
>
> JSCPTBUG.JS (c) J R Stockton 2018-01-29+
>
> Your Windows Script Host is version 5.812
> Your Script Engine is JScript 5.8.16384
> They say :
> LCT = Thu Mar 15 11:36:45 UTC 2018
> GMT = Thu, 15 Mar 2018 11:36:45 UTC
On what system?
I got, at 20:08 UK time today, in Windows 7 (and similar in
Windows 10), alleging that it is Summer Time. But Win7
wants to update, which I don't want it to do this evening
(Win10 does not want to update yet, but I've only just
turned that PC on).
Your Windows Script Host is version 5.8
They say :
LCT = Thu Mar 15 21:08:04 UTC+0100 2018
GMT = Thu, 15 Mar 2018 20:08:04 UTC
Jon Ribbens
Mar 15, 2018, 7:24:32 PM3/15/18
to
On 2018-03-15, Dr J R Stockton <J.R.St...@physics.org> wrote:
> On Thursday, March 15, 2018 at 11:39:03 AM UTC, Jon Ribbens wrote:
>> On 2018-03-15, Dr J R Stockton <see sig> wrote:
>> > Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
>>
>> That gives me:
>>
>> JSCPTBUG.JS (c) J R Stockton 2018-01-29+
>>
>> Your Windows Script Host is version 5.812
>> Your Script Engine is JScript 5.8.16384
>> They say :
>> LCT = Thu Mar 15 11:36:45 UTC 2018
>> GMT = Thu, 15 Mar 2018 11:36:45 UTC
>> ...
>
> On what system?
Windows 10 Pro Version 1709 Build 16299.248
> On Thursday, March 15, 2018 at 11:39:03 AM UTC, Jon Ribbens wrote:
>> On 2018-03-15, Dr J R Stockton <see sig> wrote:
>> > Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
>>
>> That gives me:
>>
>> JSCPTBUG.JS (c) J R Stockton 2018-01-29+
>>
>> Your Windows Script Host is version 5.812
>> Your Script Engine is JScript 5.8.16384
>> They say :
>> LCT = Thu Mar 15 11:36:45 UTC 2018
>> GMT = Thu, 15 Mar 2018 11:36:45 UTC
>> ...
>
> On what system?
This is what it says now (after 11pm) btw:
LCT = Thu Mar 15 23:19:33 UTC 2018
GMT = Thu, 15 Mar 2018 23:19:33 UTC
(the other lines were all the same as before)
Dr J R Stockton
Mar 16, 2018, 5:14:17 PM3/16/18
to
On Thursday, March 15, 2018 at 11:24:32 PM UTC, Jon Ribbens wrote:
> On 2018-03-15, Dr J R Stockton <see sig> wrote:
> > On Thursday, March 15, 2018 at 11:39:03 AM UTC, Jon Ribbens wrote:
> >> On 2018-03-15, Dr J R Stockton <see sig> wrote:
> >> > Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
> >>
> >> That gives me:
> >>
> >> JSCPTBUG.JS (c) J R Stockton 2018-01-29+
> >>
> >> Your Windows Script Host is version 5.812
> >> Your Script Engine is JScript 5.8.16384
> >> They say :
> >> LCT = Thu Mar 15 11:36:45 UTC 2018
> >> GMT = Thu, 15 Mar 2018 11:36:45 UTC
> >> ...
> >
> > On what system?
>
> Windows 10 Pro Version 1709 Build 16299.248
>
> This is what it says now (after 11pm) btw:
>
> LCT = Thu Mar 15 23:19:33 UTC 2018
> GMT = Thu, 15 Mar 2018 23:19:33 UTC
>
> (the other lines were all the same as before)
That is enough to show that your system does not have the same
> On 2018-03-15, Dr J R Stockton <see sig> wrote:
> > On Thursday, March 15, 2018 at 11:39:03 AM UTC, Jon Ribbens wrote:
> >> On 2018-03-15, Dr J R Stockton <see sig> wrote:
> >> > Out.push(" JSCPTBUG.JS\t(c) J R Stockton\t2018-01-29+")
> >>
> >> That gives me:
> >>
> >> JSCPTBUG.JS (c) J R Stockton 2018-01-29+
> >>
> >> Your Windows Script Host is version 5.812
> >> Your Script Engine is JScript 5.8.16384
> >> They say :
> >> LCT = Thu Mar 15 11:36:45 UTC 2018
> >> GMT = Thu, 15 Mar 2018 11:36:45 UTC
> >> ...
> >
> > On what system?
>
> Windows 10 Pro Version 1709 Build 16299.248
>
> This is what it says now (after 11pm) btw:
>
> LCT = Thu Mar 15 23:19:33 UTC 2018
> GMT = Thu, 15 Mar 2018 23:19:33 UTC
>
> (the other lines were all the same as before)
fault as mine do.
(a) Can JScript read the OS version etc. (other than by MS-DOS ver)?
(b) Shortly before 8 pm UK LCT :-
MS-DOS Prompt>type $datebug.js
WScript.echo(new Date())
MS-DOS Prompt>cscript //nologo $datebug.js
Fri Mar 16 20:51:24 UTC+0100 2018 (US DST !)
MS-DOS Prompt>wscript //nologo $datebug.js
[Pop-Up] Fri Mar 16 20:51:24 UTC+0100 2018 (no surprise)
In Windows Explorer, double-click $datebug.js
[Pop-Up] Fri Mar 16 19:53:10 UTC 2018 (!!)
That was in a Windows 7 PC; I got equivalent results in a
Windows 10 PC, and in a Windows XP VM in the Win 7 PC.
It seems that executing with Windows Explorer is not the
same as executing from a Command Prompt.
Are you there, EvertJan? What do you see?
Jon Ribbens
Mar 16, 2018, 7:34:47 PM3/16/18
to
On 2018-03-16, Dr J R Stockton <J.R.St...@physics.org> wrote:
> That is enough to show that your system does not have the same
> fault as mine do.
>
> (a) Can JScript read the OS version etc. (other than by MS-DOS ver)?
Using the same Win32_OperatingSystem object as before:
> That is enough to show that your system does not have the same
> fault as mine do.
>
> (a) Can JScript read the OS version etc. (other than by MS-DOS ver)?
var wmi = GetObject("WINMGMTS:\\\\.\\ROOT\\cimv2:Win32_OperatingSystem=@")
Dr J R Stockton
Apr 18, 2018, 6:15:28 AM4/18/18
to
On Friday, March 16, 2018 at 11:34:47 PM UTC, Jon Ribbens wrote:
General question :
File JSCPTBUG.JS ends with WScript.echo(SomeString) .
When, as originally intended, it is run in a Command Prompt window,
using Prompt>cscript //nologo JSCPTBUG.JS , the output is in that
window and (of course) in a fixed-pitch font.
But when is is run there using Prompt>JSCPTBUG , or it is run by
double-clicking in Windows Explorer, the output appears in a pop-up
window using a proportional-width sans-serif font. Is there
a reasonably easy way of making that pop-up use a fixed-pitch
font, without affecting anything else?
> On 2018-03-16, Dr J R Stockton <...> wrote:
> > That is enough to show that your system does not have the same
> > fault as mine do.
> >
> > (a) Can JScript read the OS version etc. (other than by MS-DOS ver)?
>
> Using the same Win32_OperatingSystem object as before:
>
> var wmi = GetObject("WINMGMTS:\\\\.\\ROOT\\cimv2:Win32_OperatingSystem=@")
> WScript.Echo(wmi.Version)
Oops - I appear to have forgotten to thank you for that. Thanks.
> > That is enough to show that your system does not have the same
> > fault as mine do.
> >
> > (a) Can JScript read the OS version etc. (other than by MS-DOS ver)?
>
> Using the same Win32_OperatingSystem object as before:
>
> var wmi = GetObject("WINMGMTS:\\\\.\\ROOT\\cimv2:Win32_OperatingSystem=@")
> WScript.Echo(wmi.Version)
General question :
File JSCPTBUG.JS ends with WScript.echo(SomeString) .
When, as originally intended, it is run in a Command Prompt window,
using Prompt>cscript //nologo JSCPTBUG.JS , the output is in that
window and (of course) in a fixed-pitch font.
But when is is run there using Prompt>JSCPTBUG , or it is run by
double-clicking in Windows Explorer, the output appears in a pop-up
window using a proportional-width sans-serif font. Is there
a reasonably easy way of making that pop-up use a fixed-pitch
font, without affecting anything else?
JJ
Apr 18, 2018, 11:58:55 AM4/18/18
to
On Wed, 18 Apr 2018 03:15:03 -0700 (PDT), Dr J R Stockton wrote:
>
> When, as originally intended, it is run in a Command Prompt window,
> using Prompt>cscript //nologo JSCPTBUG.JS , the output is in that
> window and (of course) in a fixed-pitch font.
>
> But when is is run there using Prompt>JSCPTBUG , or it is run by
> double-clicking in Windows Explorer, the output appears in a pop-up
> window using a proportional-width sans-serif font. Is there
> a reasonably easy way of making that pop-up use a fixed-pitch
> font, without affecting anything else?
In Windows, *.VBS and *.JS files are associated with WSCRIPT.EXE by default.
>
> When, as originally intended, it is run in a Command Prompt window,
> using Prompt>cscript //nologo JSCPTBUG.JS , the output is in that
> window and (of course) in a fixed-pitch font.
>
> But when is is run there using Prompt>JSCPTBUG , or it is run by
> double-clicking in Windows Explorer, the output appears in a pop-up
> window using a proportional-width sans-serif font. Is there
> a reasonably easy way of making that pop-up use a fixed-pitch
> font, without affecting anything else?
So if you want your script to be run using a console window, in the script,
before doing anything else, check the `WScript.FullName` property. If it
points to `wscript.exe` (ignoring letter case), rerun the script using
CSCRIPT.EXE instead (with all of its command line parameters), then
terminate the current script execution.
0 new messages