I too would love to know how to keep running this from Rhino, or in fact simply
from a unix command line. No-one has yet added a Rhino version to the database.
The nearest alternative seems to be node-js and npm, but npm doesn't play nice
with permissions and sudo yet.

As the file is gone from jslint.com, I have uploaded the latest jslint rhino
version I have, here, for people in the same situation as me:
http://www.darkcoding.net/jslint.js

Note that it has switched off whitespace checking.

I use inotify to watch my files and automatically run jslint (using this bash
script https://github.com/grahamking/lint_switch), so I'm  looking for a
stand-alone command line version for Unix, ideally with few dependencies.

Thanks in advance,
Graham

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> On Sun, Nov 28, 2010 at 7:18 AM, Douglas Crockford <douglas@...>wrote:
>
> >
> >
> > I am dropping support for rhino.js and wsh.js because others have improved
> > on them. If you have such an improvement, please add a record describing it.
> >
> Can you tell us the location(s) of improved versions of Rhino support? My
> googling hasn't turned up any yet.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
>
> [Non-text portions of this message have been removed]
>

On Sun, Dec 5, 2010 at 5:29 AM, graham_king_3 <graham@...> wrote:

>
> I too would love to know how to keep running this from Rhino, or in fact
> simply from a unix command line. No-one has yet added a Rhino version to the
> database. The nearest alternative seems to be node-js and npm, but npm
> doesn't play nice with permissions and sudo yet.
>
> As the file is gone from jslint.com, I have uploaded the latest jslint
> rhino version I have, here, for people in the same situation as me:
> http://www.darkcoding.net/jslint.js
>
> Note that it has switched off whitespace checking.
>
> I use inotify to watch my files and automatically run jslint (using this
> bash script https://github.com/grahamking/lint_switch), so I'm  looking
> for a stand-alone command line version for Unix, ideally with few
> dependencies.
>

jslint4java offers a command line version.  You have to say "java -jar
jslint4java.jar some.js".  There's no inotify support, but it could always
be invoked from something that has.

-Dom


[Non-text portions of this message have been removed]

Graham,

I haven’t tried it, but the table actually does list a Rhino version:

http://code.google.com/p/jslint4java/

/Jakob


Fra: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] På vegne af
graham_king_3
Sendt: 5. december 2010 06:30
Til: jslint_com@yahoogroups.com
Emne: Re: [jslint] JSLint Database



I too would love to know how to keep running this from Rhino, or in fact simply
from a unix command line. No-one has yet added a Rhino version to the database.
The nearest alternative seems to be node-js and npm, but npm doesn't play nice
with permissions and sudo yet.

As the file is gone from jslint.com, I have uploaded the latest jslint rhino
version I have, here, for people in the same situation as me:
http://www.darkcoding.net/jslint.js

Note that it has switched off whitespace checking.

I use inotify to watch my files and automatically run jslint (using this bash
script https://github.com/grahamking/lint_switch), so I'm looking for a
stand-alone command line version for Unix, ideally with few dependencies.

Thanks in advance,
Graham

--- In jslint_com@yahoogroups.com, Mark Volkmann <r.mark.volkmann@...> wrote:
>
> On Sun, Nov 28, 2010 at 7:18 AM, Douglas Crockford <douglas@...>wrote:
>
> >
> >
> > I am dropping support for rhino.js and wsh.js because others have improved
> > on them. If you have such an improvement, please add a record describing it.
> >
> Can you tell us the location(s) of improved versions of Rhino support? My
> googling hasn't turned up any yet.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
>
> [Non-text portions of this message have been removed]
>


[Non-text portions of this message have been removed]

Dom, Jakob,

  jslint4java is exactly what I was looking for. Thanks!

Graham


--- In jslint_com@yahoogroups.com, Dominic Mitchell <dom@...> wrote:
>
> jslint4java offers a command line version.  You have to say "java -jar
> jslint4java.jar some.js".  There's no inotify support, but it could always
> be invoked from something that has.
>
> -Dom
>
>
> [Non-text portions of this message have been removed]
>

I've always found, the fact that the validator's code fails to validate
to be entertaining in strange and perverse way. And the fact that it is
minified as a simple form of obfuscation, when minification is no longer
needed given that most data pipes can handle the larger files.
some of the points it appears to fail
usage of evalusage of ++ and -- in some implementationsusage of "use
strict"; while containing Strict violationshaving Empty blocks


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:
I've always found, the fact that the validator's code fails to validate to be
entertaining in strange and perverse way. And the fact that it is minified as a
simple form of obfuscation, when minification is no longer needed given that
most data pipes can handle the larger files.
some of the points it appears to fail
usage of eval usage of ++ and -- in some implementations
usage of "use strict";
while containing Strict violations
having Empty blocks
--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:

Quick clarification

"without fudging" on points that Douglas vehemently says we should not use.

--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:
>
>
> --- In jslint_com@yahoogroups.com, "abyssoft@" <abyssoft@> wrote:
> I've always found, the fact that the validator's code fails to validate to be
entertaining in strange and perverse way. And the fact that it is minified as a
simple form of obfuscation, when minification is no longer needed given that
most data pipes can handle the larger files.
> some of the points it appears to fail
> usage of eval usage of ++ and -- in some implementations
> usage of "use strict";
> while containing Strict violations
> having Empty blocks
> --- In jslint_com@yahoogroups.com, "abyssoft@" <abyssoft@> wrote:
>
> Quick clarification
>
> "without fudging" on points that Douglas vehemently says we should not use.
>

changing line 5450 from
                 predefined['eval'] =
to
                 predefined[["e", "v", "a", "l"].join("")] =

Fixes the need for evil : false
No longer any strict violations in most recent upload of fulljslint.js

8D

Would still like to see usage of ^ regex operator removed from lines 953, 958,
and 1033 as it is recommended against use,
or at least rational for use in comment.

Quick side question,

document.defaultView === window //for the major Non IE browsers

What is the equivalent for IE? as window is not defined when one picks browser :
true

--- In jslint_com@yahoogroups.com, "abyssoft@..." <abyssoft@...> wrote:

> changing line 5450 from
>                 predefined['eval'] =
> to
>                 predefined[["e", "v", "a", "l"].join("")] =


Of course I am not going to take your advice because it would stupid to, which
perhaps was your point.

JSLint should be run against source code, not minified code. If you can find an
example of a bug that is in JSLint that JSLint should have been able to detect,
I would be very happy to hear about it.

--- In jslint_com@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> --- In jslint_com@yahoogroups.com, "abyssoft@" <abyssoft@> wrote:
>
> > changing line 5450 from
> >                 predefined['eval'] =
> > to
> >                 predefined[["e", "v", "a", "l"].join("")] =
>
>
> Of course I am not going to take your advice because it would stupid to, which
perhaps was your point.
>
> JSLint should be run against source code, not minified code. If you can find
an example of a bug that is in JSLint that JSLint should have been able to
detect, I would be very happy to hear about it.
>

Douglas, that was indeed my point.

A little extra background, I was running fulljslint.js un-minified as the source
through itself, when I saw that no more strict issues remained which was quite
nice.

As for the ^ (not) operator is the mentioning that it is unsafe more of a piece
of advice for the novice to regex or more of a concrete rule? I've been playing
with regex for a while now and find the ^ (not) operator quite useful and so
typically have regexp:false.

https://gist.github.com/733715

{
   "ID3v1": {
     "title": "Michael Bolton \'\' Said i lov",
     "artist": "Michael Bolton \'\' Said i lov",
     "genre": "Blues"
   }
}

Node.js's JSON.parse does not parse this, neither does jsonlint.com, but
jslint.com reports that it is valid.

--- In jslint_com@yahoogroups.com, "coolaj86" <coolaj86@...> wrote:

> {
>   "ID3v1": {
>     "title": "Michael Bolton \'\' Said i lov",
>     "artist": "Michael Bolton \'\' Said i lov",
>     "genre": "Blues"
>   }
> }

Thanks. Please try it now.

Works for me.

Thanks.

AJ ONeal


On Wed, Dec 8, 2010 at 1:37 PM, Douglas Crockford <douglas@...>wrote:

>
>
> --- In jslint_com@yahoogroups.com <jslint_com%40yahoogroups.com>,
> "coolaj86" <coolaj86@...> wrote:
>
> > {
> > "ID3v1": {
> > "title": "Michael Bolton \'\' Said i lov",
> > "artist": "Michael Bolton \'\' Said i lov",
> > "genre": "Blues"
> > }
> > }
>
> Thanks. Please try it now.
>
>
>


[Non-text portions of this message have been removed]

jslint.com says that this is valid, Firefox JSON.parse agrees

jsonlint.com disagrees as does v8 JSON.parse / node.js

{
     "ID3v1" : {
         "title" : "TRACK 11",
         "artist" : "KORINI 11",
         "comment" : "ALTOMP3 MAKER (YUANSOFT.COM)\v"
     }
}

The obvious answer seems to be to drop "\v" as an invalid character (and not
worry about it). Always. Period.
But how should a vertical tab be handled per spec?

AJ ONeal


[Non-text portions of this message have been removed]

I think I understand now: "\v" should instead be escaped as "\u000B".

... additionally, a bug should be filed for any software that uses vertical
tabs.

AJ ONeal

On Thu, Dec 9, 2010 at 11:09 PM, AJ ONeal <coolaj86@...> wrote:

> jslint.com says that this is valid, Firefox JSON.parse agrees
>
> jsonlint.com disagrees as does v8 JSON.parse / node.js
>
> {
>     "ID3v1" : {
>         "title" : "TRACK 11",
>         "artist" : "KORINI 11",
>         "comment" : "ALTOMP3 MAKER (YUANSOFT.COM)\v"
>     }
> }
>
> The obvious answer seems to be to drop "\v" as an invalid character (and
> not worry about it). Always. Period.
> But how should a vertical tab be handled per spec?
>
> AJ ONeal
>


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, AJ ONeal <coolaj86@...> wrote:
>
> jslint.com says that this is valid, Firefox JSON.parse agrees
>
> jsonlint.com disagrees as does v8 JSON.parse / node.js

\v is not allowed by JSON. Please try it now.

var i;

for ( i=0 ; i<10 ; i++ )
{
  /* some code */
}

The i++ here is straight from K&R C, and so should be expected! I haven't found
a previous remark about this in the group, so is it a new feature?

grahamj_42 <grahamj42@...> wrote:

> var i;
>
> for ( i=0 ; i<10 ; i++ )
> {
> /* some code */
> }
>
> The i++ here is straight from K&R C, and so should be expected! I haven't
found a previous remark about this in the group, so is it a new feature?


From http://www.jslint.com/lint.html

++ and --

The ++ (increment) and -- (decrement) operators have been known to contribute to
bad code by encouraging excessive trickiness. They are second only to faulty
architecture in enabling to viruses and other security menaces. There is a
plusplus option that prohibits the use of these operators.



for (i = 0; i < 10; i += 1)
{
	 // some code
}

works just as well.

Harry.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 12/12/2010 04:53 PM, grahamj_42 wrote:
> The i++ here is straight from K&R C, and so should be expected! I
> haven't found a previous remark about this in the group, so is it a new
> feature?
>

Besides what grahamj_42 indicated, citing a reference for a different
language doesn't make sense. If such a thing existed, cite K&R
JavaScript instead. However, even for C, K&R is a dated source that I've
seen encourage bad practices. However, that's a discussion for some
other list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJNBXJyAAoJEBu6+LqX8zdcxEoP/2xAEFxH/L69i9FVLfzH/Xzl
nzKJhQmJ9xFMxAxe0TVWN/z+KtBJAPTQpqv7S5v3BKvGMNhfNhNTdKE0eGJHQucK
w/FucSmsN86TpUALfH2bMUrsP9gd7gZu1uqPMFaiG4j1iUsPFkL3TWFPXD3Gl+nl
TQnHw1HCYhbmfM95t3FRD96fQXDYzabLw10KyxOZ5tNHsg6XmLcw+n4MTv1tw1EM
ct6ZfASwYMx4JXJYOOM9ci1VGf7noTz8PPopLZBD10HMAJq4nEO3AR0YtxjqWRPD
884zCSIUWVHoB+n0lkksmDVyhVkSUhSIG5z5IIHGVYOQObSYdT9GO6Yk391LRFpy
KbWVYwMi8R/DgLcCvV2T5ui6gsM/IuWn099X/QFKceuMVb647RUIvQJSz2ZAWqiB
4LcToNpWnZQHPRxcphfGoufdbyJt3tRcgoZX0xjH5zyTPLnYYCH23VEzYJRguTGb
+SGbM0rJ1jfjRAxSf0CN3aZRP3QQQCSZ7QnOeWWxbP1NRHcyi13MmUHrKi0KBZ7o
Y398aAsjDDWiGkESe4u24MOBfKbH6sUb1q+D+cOB8ABZiODJrxalxpGKq3a0IhtD
4Hyr83GHQ6LBZ/wXzCimGSwyBK2X6umBvzdYQZNZNK6DarguYDLCyKWsUmXdRX8O
uaFoYugZzreLk2Rhl3Pm
=ua5e
-----END PGP SIGNATURE-----



[Non-text portions of this message have been removed]

On Sun, Dec 12, 2010 at 10:53 PM, grahamj_42 <grahamj42@...> wrote:

>
>
> var i;
>
> for ( i=0 ; i<10 ; i++ )
> {
> /* some code */
> }
>
>
Everybody knows that this is bad !
In fact, it should be:

for ( i=0 ; i<10 ; ++i )
{
/* some code */
}

And yes, I'm an old C coder, and, a long time ago, compilers were more
efficient with ++i than with i++. In this case, an useless read of the i
variable was generated.

Frankly, I don't see how it's bad.
Of course, ++ in expressions is terrible (like if (i++ > 10), or
a=(i++>10)?1:0;), but when there is no confusion, I find this very elegant.

JC


[Non-text portions of this message have been removed]

On Mon, Dec 13, 2010 at 1:46 AM, Jean-Charles Meyrignac <
jcmeyrignac@...> wrote:

> On Sun, Dec 12, 2010 at 10:53 PM, grahamj_42 <grahamj42@...> wrote:
>
> >
> >
> > var i;
> >
> > for ( i=0 ; i<10 ; i++ )
> > {
> > /* some code */
> > }
> >
> >
> Everybody knows that this is bad !
>

"everybody"?


> In fact, it should be:
>
> for ( i=0 ; i<10 ; ++i )
> {
> /* some code */
> }
>
>
This also fails to pass muster with JSLint.


> And yes, I'm an old C coder, and, a long time ago, compilers were more
> efficient with ++i than with i++. In this case, an useless read of the i
> variable was generated.
>

This bears no relevance to JavaScript.


> Frankly, I don't see how it's bad.
> Of course, ++ in expressions is terrible (like if (i++ > 10), or
> a=(i++>10)?1:0;), but when there is no confusion, I find this very elegant.
>

-Dom


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, Brant Gurganus <brant@...> wrote:

> Besides what grahamj_42 indicated, citing a reference for a different
> language doesn't make sense. If such a thing existed, cite K&R
> JavaScript instead. However, even for C, K&R is a dated source that I've
> seen encourage bad practices. However, that's a discussion for some
> other list.

>

And where did the JavaScript 'for' construct come from, if not from C?

However, you missed the irony in my post. As anyone who has learned C finds this
way of writing a loop natural, 'i++' is to be expected, and if JSLint doesn't
like this perfectly unambiguous expression, it should criticise it in different
terms.

I for one think the message/error is pretty clear. You turned on an option to
disallow the use of '++'. Then you used '++'. That seems 'unexpected' to me.


It is not the way in which you use '++' that is unexpected, but that you use it
at all.


/Jakob



   _____

From: grahamj_42 [mailto:grahamj42@...]
To: jslint_com@yahoogroups.com
Sent: Mon, 13 Dec 2010 15:55:32 +0100
Subject: Re: [jslint] Unexpected use of ++






--- In jslint_com@yahoogroups.com, Brant Gurganus <brant@...> wrote:

   > Besides what grahamj_42 indicated, citing a reference for a different
   > language doesn't make sense. If such a thing existed, cite K&R
   > JavaScript instead. However, even for C, K&R is a dated source that I've
   > seen encourage bad practices. However, that's a discussion for some
   > other list.

   >

   And where did the JavaScript 'for' construct come from, if not from C?

   However, you missed the irony in my post. As anyone who has learned C finds
this way of writing a loop natural, 'i++' is to be expected, and if JSLint
doesn't like this perfectly unambiguous expression, it should criticise it in
different terms.




[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, "grahamj_42" <grahamj42@...> wrote:
>
> var i;
>
> for ( i=0 ; i<10 ; i++ )
> {
>  /* some code */
> }
>
> The i++ here is straight from K&R C, and so should be expected! I
> haven't found a previous remark about this in the group, so is it a
> new feature?

K&R is an excellent book, but it is about an entirely different language. If you
are going to be working with JavaScript, you need relevant documentation.

One of the premises of a code quality tool is that there are features in
languages that are problematic. The problem with bad parts isn't that they are
useless, but that they are dangerous. They should be avoided if there are safer
alternatives.

In my opinion, ++ and -- are dangerous. They have been implicated in some of the
worst OS security bugs. And they seem to confuse people who sometimes use i++
when the mean ++i (as you just did). Confusion leads to bugs.

So JSLint has an option to warn when they are used. If you are wise, you will
change your code to i += 1. But if you choose not to, then stop turning that
option on.

Some famous websites are failing on the latest browsers because they have been
concatenating strict mode scripts with non-strict mode scripts. This causes the
non-strict scripts to fail.

There are two ways to specify strict mode. The first is to place "use strict";
at the top of the file. This contributes to the comcatenation failure. The
second is to place "use strict"; at the top of a file. This gives the strictness
function scope, which is much more reliable.

JSLint's option.strict now accepts the second form. Soon it will reject the
first form.

I haven't used a browser in which "use strict" does anything yet,
but is this assumption correct?

// begin myfile.js:
"use strict";
(function () {
     // this function is in strict mode
     var nullthing = this;
}());
(function () {
     // this function is not in strict mode
     var globalObj = this;
}());
// end myfile.js



or should I do something like this?

(function () {
     "use strict";
     (function () {
     }());
}());

AJ ONeal


On Mon, Dec 13, 2010 at 3:53 PM, Douglas Crockford <douglas@...>wrote:

>
>
> Some famous websites are failing on the latest browsers because they have
> been concatenating strict mode scripts with non-strict mode scripts. This
> causes the non-strict scripts to fail.
>
> There are two ways to specify strict mode. The first is to place "use
> strict"; at the top of the file. This contributes to the comcatenation
> failure. The second is to place "use strict"; at the top of a file. This
> gives the strictness function scope, which is much more reliable.
>
> JSLint's option.strict now accepts the second form. Soon it will reject the
> first form.
>
>
>


[Non-text portions of this message have been removed]

On Mon, Dec 13, 2010 at 11:53 PM, Douglas Crockford
<douglas@...>wrote:

> The first is to place "use strict"; at the top of the file.



> The second is to place "use strict"; at the top of a file.


I assume you meant to say 'function' in that second line?   (Otherwise the
only diff I see is 'a' vs. 'the'). A bit of googling led me to

http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/

hence the assumption.

--
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
         http://www.hebbut.net/
mail:   ger@...
mobile: +31-6-11 120 978
--------------------------------------------------


[Non-text portions of this message have been removed]

On Tue, Dec 14, 2010 at 12:07 AM, AJ ONeal <coolaj86@...> wrote:

> I haven't used a browser in which "use strict" does anything yet,
> but is this assumption correct?
>
> // begin myfile.js:
> "use strict";
> [...]


or should I do something like this?
>
> (function () {
>    "use strict";
>    (function () {
>    }());
> }());
>

Pending an answer from Mr. Crockford, I'd say the latter is the preferred
one.


--
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
         http://www.hebbut.net/
mail:   ger@...
mobile: +31-6-11 120 978
--------------------------------------------------


[Non-text portions of this message have been removed]

--- In jslint_com@yahoogroups.com, AJ ONeal <coolaj86@...> wrote:
>
> Iis this assumption correct?
>
> // begin myfile.js:
> "use strict";
> (function () {
>     // this function is in strict mode
>     var nullthing = this;
> }());
> (function () {
>     // this function is not in strict mode

Wrong. All functions in this file are strict. Also, if you concatenate any
programs to the end of this file, they will be strict, too.

>     var globalObj = this;
> }());
> // end myfile.js
>
>
>
> or should I do something like this?
>
> (function () {
>     "use strict";
>     (function () {
>     }());
> }());

This is better. Both functions are strict.

You've specified "at the top of the file" twice.  Did you intend to identify
the second as "the top of a function"?

Rob


-----Original Message-----
From: jslint_com@yahoogroups.com [mailto:jslint_com@yahoogroups.com] On
Behalf Of Douglas Crockford
Sent: Monday, December 13, 2010 3:54 PM
To: jslint_com@yahoogroups.com
Subject: [jslint] option.strict

Some famous websites are failing on the latest browsers because they have
been concatenating strict mode scripts with non-strict mode scripts. This
causes the non-strict scripts to fail.

There are two ways to specify strict mode. The first is to place "use
strict"; at the top of the file. This contributes to the comcatenation
failure. The second is to place "use strict"; at the top of a file. This
gives the strictness function scope, which is much more reliable.

JSLint's option.strict now accepts the second form. Soon it will reject the
first form.

--- In jslint_com@yahoogroups.com, "Rob Richardson" <erobrich@...> wrote:
>
> You've specified "at the top of the file" twice.  Did you intend to identify
> the second as "the top of a function"?

Yes.