General Syntax rules - Any document specifying?


(Tony Su) #1

I've been curious about what I've been seeing and experimenting with...

  • There seems to be no set rule whether to use double-quotes or single
    quotes, they seem to work interchangeably for all commands using curl or
    http. Or, more expectedly can be omitted altogether if the string contains
    no spaces.

  • Camel case (or more specifically upper case) is not supported throughout
    for anything not a label. Seems to still work (thankfully) for labels like
    hostnames.

  • Also, might be more of a JSON syntax standard but I'm finding spaces and
    tabs between operands are optional and don't affect whether the statement
    will work or not.

There might be others?

Tony

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/743c3f20-16e5-4249-913d-3470e7bda38f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Brian Yoder) #2

Tony,

(1) Your first question seems to be about the curl command. If so, then it
follows shell script rules. In most Unix shell scripts, double-quotes
preserve spaces and such, but allow for variable substitution. Sngle-quotes
also preserve spaces but do not allow variable substitution and preserve
all characters as-is. Example:

export FIELD=_all

curl -XGET "http://localhost:9200/$FIELD/_mapping" is converted by the
shell to: curl -XGET http://localhost:9200/_all/_mapping

curl -XGET 'http://localhost:9200/$FIELD/_mapping' is converted by the
shell to: curl -XGET http://localhost:9200/$FIELD/_mapping

So single quotes are usually preferred so that the & and ? characters in
URL parameter lists are not interpreted as shell characters. But if you
want to parameterize a curl command, you may need to use double-quotes for
parts, and single-quotes for the other parts. This is all standard shell
programming.

(2) Camel case is OK for hostnames because hostnames are typically
insensitive. But JSON and ES are case-sensitive.

(3) This is a JSON standard. {"field":"name"} and { "field" : "name" } are
the same, but one or the other is prettier.

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/69adf245-d360-4cde-a01e-779d3e44d334%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #3

Thx for the complete answer.

Tony

On Tuesday, February 18, 2014 11:44:22 AM UTC-8, InquiringMind wrote:

Tony,

(1) Your first question seems to be about the curl command. If so, then it
follows shell script rules. In most Unix shell scripts, double-quotes
preserve spaces and such, but allow for variable substitution. Sngle-quotes
also preserve spaces but do not allow variable substitution and preserve
all characters as-is. Example:

export FIELD=_all

curl -XGET "http://localhost:9200/$FIELD/_mapping" is converted by the
shell to: curl -XGET http://localhost:9200/_all/_mapping

curl -XGET 'http://localhost:9200/$FIELD/_mapping' is converted by the
shell to: curl -XGET http://localhost:9200/$FIELD/_mapping

So single quotes are usually preferred so that the & and ? characters in
URL parameter lists are not interpreted as shell characters. But if you
want to parameterize a curl command, you may need to use double-quotes for
parts, and single-quotes for the other parts. This is all standard shell
programming.

(2) Camel case is OK for hostnames because hostnames are typically
insensitive. But JSON and ES are case-sensitive.

(3) This is a JSON standard. {"field":"name"} and { "field" : "name"
} are the same, but one or the other is prettier.

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/7d884b8f-d1d4-4be1-aeef-ffaaf451340d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #4

Curious...

Since JSON and ES do not support upper case,
Would this possibly cause some confusion about bits/Bytes and milli/Mega?

Should it be assumed therefor that ES never supports bits and milli? That
the lower case abbreviations will always apply to the normally capitalized
measures Bytes and Mega?

Thx,
Tony

On Tuesday, February 18, 2014 1:26:06 PM UTC-8, Tony Su wrote:

Thx for the complete answer.

Tony

On Tuesday, February 18, 2014 11:44:22 AM UTC-8, InquiringMind wrote:

Tony,

(1) Your first question seems to be about the curl command. If so, then
it follows shell script rules. In most Unix shell scripts, double-quotes
preserve spaces and such, but allow for variable substitution. Sngle-quotes
also preserve spaces but do not allow variable substitution and preserve
all characters as-is. Example:

export FIELD=_all

curl -XGET "http://localhost:9200/$FIELD/_mapping" is converted by the
shell to: curl -XGET http://localhost:9200/_all/_mapping

curl -XGET 'http://localhost:9200/$FIELD/_mapping' is converted by the
shell to: curl -XGET http://localhost:9200/$FIELD/_mapping

So single quotes are usually preferred so that the & and ? characters in
URL parameter lists are not interpreted as shell characters. But if you
want to parameterize a curl command, you may need to use double-quotes for
parts, and single-quotes for the other parts. This is all standard shell
programming.

(2) Camel case is OK for hostnames because hostnames are typically
insensitive. But JSON and ES are case-sensitive.

(3) This is a JSON standard. {"field":"name"} and { "field" : "name"
} are the same, but one or the other is prettier.

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/44225489-afe7-41f0-b9a9-f0cc7d432205%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Brian Yoder) #5

Tony,

JSON and ES both support uppercase. It's just that "FOO" and "foo" are two
completely different field names. Hence, case-sensitive.

In some contexts, ES does not support uppercase. For example, names of
indices. But field names can be in lowercase, uppercase, or mixed case. I
believe that the docs cover this well already.

For distance units, ES will soon support NM for nautical miles. Hence,
12.3nm is reserved for 12.3 nanometers, while 12.3NM will mean 12.3
nautical miles.

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/908cf9eb-6849-42d9-b6d1-e50281d4883c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Tony Su) #6

OK,
Was just thrown when I see "mb" represent MegaBytes in elasticsearch.yml

Tony

On Tuesday, February 18, 2014 3:12:16 PM UTC-8, InquiringMind wrote:

Tony,

JSON and ES both support uppercase. It's just that "FOO" and "foo" are two
completely different field names. Hence, case-sensitive.

In some contexts, ES does not support uppercase. For example, names of
indices. But field names can be in lowercase, uppercase, or mixed case. I
believe that the docs cover this well already.

For distance units, ES will soon support NM for nautical miles. Hence,
12.3nm is reserved for 12.3 nanometers, while 12.3NM will mean 12.3
nautical miles.

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/b023a50b-6bff-4fac-ac60-24db2164fd8a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Brian Yoder) #7

Hmmmm. I see that the
src/main/java/org/elasticsearch/common/unit/ByteSizeUnit.java file defines
the units by uppercase enum name (e.g. MB), while the comments inside the
config/elasticsearch.yml file suggest lowercase (e.g. mb).

Perhaps there's an issue? Or am I reading something incorrectly?

Brian

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/412d68a9-68f0-428b-b5b4-3ba8fc741041%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Binh Ly) #8

Should be fine, it is converted to lowercase in code. :slight_smile:

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/84117bd5-d3e0-4016-b3fa-4df07cc2d21d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(Brian Yoder) #9

Ah, ok! I couldn't find it in the code, but I only did a quick check.
However, TimeValue and DistanceUnit are both case-sensitive.

Thanks for confirming!

Brian

On Wednesday, February 19, 2014 8:51:17 AM UTC-5, Binh Ly wrote:

Should be fine, it is converted to lowercase in code. :slight_smile:

--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/38beacc6-0958-43e0-83b2-36e400eff9bf%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


(system) #10