John Brock | 3 Jan 03:46 2006
Picon

Re: Re: A suggestion for implementing hashes in Fish

On Tue, Dec 27, 2005 at 12:53:19PM +1100, Netocrat wrote:
> John Brock wrote in a message he forwarded:
> [...]
> >>My suggestion is that by using a different syntax you can always
> >>look at any array as a hash.

> [and vice versa, by mapping a hash to a sequential list as key1, value1, 
> key2, value2, ...]
> 
> A hash datatype requires a new operator to access the hash keys (so 
> afaics it's possible to avoid different braces per Axel's preference, 
> but /something/ new has to be added).  John's idea of two indexing 
> bracing styles achieves this, but interspersing the hash values with the 
> keys as part of a get-keys operator is redundant.
> 
> Another possible get-keys operator is a modified prefix, e.g.  <at>  rather 
> than $ - so  <at> hash[1] would return the first key and  <at> hash[count $hash] 
> would return the last.  This has the advantage of being able to access 
> the entire key list using  <at> hash, which can be passed as an argument to a 
> for loop or to echo or printf.  The alternative indexing operator could 
> achieve this through something like {*} for all values and { <at> } for all 
> keys, but this is less intuitive and not backward-compatible with 
> existing syntax, since $hash unadorned would return keys as well as values.
> 
> IME the mapping that John describes is rarely used.  So supporting it in 
> the get-keys operator doesn't warrant the inconvenience of having only 
> odd-index access to the list of hash keys, and losing backward 
> compatibility with the meaning of unadorned $array.

In Perl if you assign a hash to an array you get alternating keys
(Continue reading)

Netocrat | 3 Jan 04:23 2006
Picon

Re: Re: A suggestion for implementing hashes in Fish

John Brock wrote:
> On Tue, Dec 27, 2005 at 12:53:19PM +1100, Netocrat wrote:
>>John Brock wrote in a message he forwarded:
>>[...]
>>>>My suggestion is that by using a different syntax you can always
>>>>look at any array as a hash.
>>[and vice versa, by mapping a hash to a sequential list as key1, value1, 
>>key2, value2, ...]
>>
>>A hash datatype requires a new operator to access the hash keys (so 
>>afaics it's possible to avoid different braces per Axel's preference, 
>>but /something/ new has to be added).  John's idea of two indexing 
>>bracing styles achieves this, but interspersing the hash values with the 
>>keys as part of a get-keys operator is redundant.
>>
>>Another possible get-keys operator is a modified prefix, e.g.  <at>  rather 
>>than $ - so  <at> hash[1] would return the first key and  <at> hash[count $hash] 
>>would return the last.  This has the advantage of being able to access 
>>the entire key list using  <at> hash, which can be passed as an argument to a 
>>for loop or to echo or printf.  The alternative indexing operator could 
>>achieve this through something like {*} for all values and { <at> } for all 
>>keys, but this is less intuitive and not backward-compatible with 
>>existing syntax, since $hash unadorned would return keys as well as values.
>>
>>IME the mapping that John describes is rarely used.  So supporting it in 
>>the get-keys operator doesn't warrant the inconvenience of having only 
>>odd-index access to the list of hash keys, and losing backward 
>>compatibility with the meaning of unadorned $array.
> 
> In Perl if you assign a hash to an array you get alternating keys
(Continue reading)

Axel Liljencrantz | 4 Jan 15:03 2006
Picon

I18n support for fish

Hello, all

Since the total number of people who have expressed an interest at translating fish to another language at one time has now grown to a stunning TWO people, I have gone ahead and spent far too much of the last week _not_ playing with my Xbox 360, and instead adding gettext support for fish. The darcs tree should contain the result, including a swedish translation.

Notes:

The code has passed by own rigorous test suite (a.k.a. make all), but I don't have access to lots of cool machines, so I'd be very interested in hearing if things compile on various platforms. There are some semi-big changes in there... If you want to understand nothing, just doewnload the latset darcs fish, install it and 'set LANG sv_SE.utf8'. Prepare for some åäö!

The support is incomplete, there is still a small number of strings in fish itself missing, and all the shellscript code (including the greeting message) is also untranslated. Also, there is no infrastructure for translating the fish manual or the help messages for commands, etc. These things will be coming, but just adding gettext support for the C code was a pretty big change, espacially since gettext doesn't really know how to handle wide characters.

Read the documentation section on how to do a translation for more info on how to do a translation.

I tried out both catgets and gettext, which seem to be the common, open i18n libraries. The main differences between these two is that gettext indexes translations based on the english-language string, while catgets indexes translations on a unique ID that you have to manually assign to every translatable string. Translation don't seem to get a lot of love, though. The gettext example program doesn't compile, nor does the catgets example provided in the Glibc manual. The gettext manuals seems to partly be written as a discussion with itself. You'd almost think _I_ wrote them...

Pros for gettext:
The gettext solution is much easier to implement. Just add _() around any string that should be translated, and do some initial setup.
Available for translation of shellscripts in an easy, readable way

Pros for catgets
The catgets solution is easier to maintain, since you avoid the massive headache caused when you want to change an existing string in the sourcecode. (Gettext helps a bit by providing fuzzy matching, but my internal tests of the reliablity of this tool where not encouraging)
catgets also avoids some of the problems where you can have the same string mean different things in different contexts. As an illustration of what this means, in an early windows version here in Sweden, the screensaver 'Space', which showed a speedy flight through space, was called 'mellanslag', which is the swedish name for the spacebar key.
catgets is more portable. Both seems to exist on Linux, Solaris and *BSD (only through ports), but only catgets is available on OSX and various other Unixes. This is not as big of an issue as it may seem, since it can be fixed by the user installing gettext. One could even bundle gettext with fish.

I dont really care either way about the catgets vs. gettext interface, both have their advantages. In the end, I chose to go with gettext because I felt that providing translatable strings in a readable, standardized way from shellscripts was an even bigger showstopper than translations on OSX out of the box.

I have made sure that fish should build even without gettext, but since _I_ wrote it, I don't expect the fallback to work on the first try. ;-) Please do test!

--
Axel

Isak Savo | 4 Jan 16:27 2006
Picon

Re: I18n support for fish

Hi, I do translation coordination for the Autopackage project, and as
such, has some experience with gettext and the GNU i18n
infrastructure. I have never used catgets though, so I won't comment
on that.

2006/1/4, Axel Liljencrantz <liljencrantz@...>:
>  Notes:
>
>  The support is incomplete, there is still a small number of strings in fish
> itself missing, and all the shellscript code (including the greeting
> message) is also untranslated. Also, there is no infrastructure for
> translating the fish manual or the help messages for commands, etc. These
> things will be coming, but just adding gettext support for the C code was a
> pretty big change, espacially since gettext doesn't really know how to
> handle wide characters.

Hmm, are you sure about this? I know I've used UTF-8 as the encoding
for the reference language (english) and it works fine. Some of the
reference strings contained multibyte characters IIRC. Granted though,
I use intltool as a wrapper over gettext so it might apply some magic
to make it work.

>  Read the documentation section on how to do a translation for more info on
> how to do a translation.

I've written a tutorial/introduction about this for the Autopackage project:
   http://www.autopackage.org/docs/i18n/
It's targeted against translating autopackage, but most of it applies
to other projects using gettext.

>  Pros for gettext:
>  The gettext solution is much easier to implement. Just add _() around any
> string that should be translated, and do some initial setup.
>  Available for translation of shellscripts in an easy, readable way

Not to mention the amount of other OSS projects using it, and tools
available to aid translations. Thinking of KBabel, gtranslator etc.

>  Pros for catgets
>  The catgets solution is easier to maintain, since you avoid the massive
> headache caused when you want to change an existing string in the
> sourcecode. (Gettext helps a bit by providing fuzzy matching, but my
> internal tests of the reliablity of this tool where not encouraging)
>  catgets also avoids some of the problems where you can have the same string
> mean different things in different contexts. As an illustration of what this
> means, in an early windows version here in Sweden, the screensaver 'Space',
> which showed a speedy flight through space, was called 'mellanslag', which
> is the swedish name for the spacebar key.

Indeed a problem, but not unsolvable. Newer versions of gettext should
support the concept of "context" strings, meaning you can have
something like:

  msgctxt "Screensaver"
  msgid "Space"
  msgstr "Rymd"
and
  msgctxt "Keyboard Key"
  msgid "Space"
  msgstr "Mellanslag"
This is solved in the source code by something like:
  pgettext ("Screensaver", "Space")
instead of just
  gettext ("Space")

GLib (used by GTK) has another solution which prepends the msgid with
the context separated by a pipe (|) character:
  msgid "Screensaver|Space"
  msgstr "Rymd"
See http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html#Q-:CAPS

I haven't used any of them, and I don't know how well spread the
gettext context support is (the first of my examples). And I assume
you don't want fish to depend on glib :-)

Isak

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
Axel Liljencrantz | 4 Jan 16:47 2006
Picon

Re: I18n support for fish



On 1/4/06, Isak Savo <isak.savo <at> gmail.com> wrote:
Hi, I do translation coordination for the Autopackage project, and as
such, has some experience with gettext and the GNU i18n
infrastructure. I have never used catgets though, so I won't comment
on that.

2006/1/4, Axel Liljencrantz < liljencrantz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>  Notes:
>
>  The support is incomplete, there is still a small number of strings in fish
> itself missing, and all the shellscript code (including the greeting
> message) is also untranslated. Also, there is no infrastructure for
> translating the fish manual or the help messages for commands, etc. These
> things will be coming, but just adding gettext support for the C code was a
> pretty big change, espacially since gettext doesn't really know how to
> handle wide characters.

Hmm, are you sure about this? I know I've used UTF-8 as the encoding
for the reference language (english) and it works fine. Some of the
reference strings contained multibyte characters IIRC. Granted though,
I use intltool as a wrapper over gettext so it might apply some magic
to make it work.

I was unclear, but I think what I said was correct. There is a difference between wide character strings and multibyte character strings. gettext handles multibyte character strings, such as those encoded in UTF-7 and UTF-8 just fine. What it doesn't handle, at least not  according to the gettext manual or in the latest sources, is _wide_ character strings, i.e. strings that use exactly one 4-byte wchar_t character instead of one or more 1-byte char characters to encode any single character.

>  Read the documentation section on how to do a translation for more info on
> how to do a translation.

I've written a tutorial/introduction about this for the Autopackage project:
   http://www.autopackage.org/docs/i18n/
It's targeted against translating autopackage, but most of it applies
to other projects using gettext.

Very nice. How I wish I'd found your page before I sat down and did all the hard work. Would have saved me a bunch of time. I'll add a link to your page from the fish homepage in the hope that it will improve your Google-ranking.

>  Pros for gettext:
>  The gettext solution is much easier to implement. Just add _() around any
> string that should be translated, and do some initial setup.
>  Available for translation of shellscripts in an easy, readable way

Not to mention the amount of other OSS projects using it, and tools
available to aid translations. Thinking of KBabel, gtranslator etc.

There I go only thinking of myself. I never bothered to investigate the situation for translators. :(

>  Pros for catgets
>  The catgets solution is easier to maintain, since you avoid the massive
> headache caused when you want to change an existing string in the
> sourcecode. (Gettext helps a bit by providing fuzzy matching, but my
> internal tests of the reliablity of this tool where not encouraging)
>  catgets also avoids some of the problems where you can have the same string
> mean different things in different contexts. As an illustration of what this
> means, in an early windows version here in Sweden, the screensaver 'Space',
> which showed a speedy flight through space, was called 'mellanslag', which
> is the swedish name for the spacebar key.

Indeed a problem, but not unsolvable. Newer versions of gettext should
support the concept of "context" strings, meaning you can have
something like:

  msgctxt "Screensaver"
  msgid "Space"
  msgstr "Rymd"
and
  msgctxt "Keyboard Key"
  msgid "Space"
  msgstr "Mellanslag"
This is solved in the source code by something like:
  pgettext ("Screensaver", "Space")
instead of just
  gettext ("Space")

Cool. I guess that makes sense.

GLib (used by GTK) has another solution which prepends the msgid with
the context separated by a pipe (|) character:
  msgid "Screensaver|Space"
  msgstr "Rymd"
See http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html#Q-:CAPS

Doesn't that mean you need to provide a special translatiuon for the C locale, so that it will output Space instead of Screensaver|Space?

I haven't used any of them, and I don't know how well spread the
gettext context support is (the first of my examples). And I assume
you don't want fish to depend on glib :-)

I hope to avoid this mostly by having few enough translatable strings that no such duplicates will be found! :)
Currently, there are ~250 translatable strings, I doubt the number will be over 500 when fish is fully translated.

Isak

--
Axel


Axel Liljencrantz | 4 Jan 17:44 2006
Picon

Re: Re: A suggestion for implementing hashes in Fish


Sorry for not partaking in this discussion sooner...

On 1/3/06, Netocrat < netocrat-rGYn+TmxqGy6c6uEtOJ/EA@public.gmane.org> wrote:
John Brock wrote:

[...]

> In Perl if you assign a hash to an array you get alternating keys
> and values, which is where I got this idea.  The additional thought
> that occurred to me was that there was really no reason why you
> needed two data types with two namespaces -- that in fact you could
> use a single data type both ways.  This just seems simpler to me.
> Why multiply entities if you don't have to?

Exactly.  And the PHP-equivalent alternative avoids multiple entities.
It's simpler than Perl's hash/array duality.  Your proposal retains
multiple entities - a hash (using {}) and an array (using []).
Regardless that /internally/ you propose these be stored in a common
format, from the user's perspective they are mappings between two
different data types.  I've pointed out that your hash model could be
used identically to our current proposal, meaning that your hash=>array
mapping index operator (using [], although for backwards compatibility
the meaning of your [] and {} operators would need to be reversed) is an
"optional extra", but you don't seem to recognise it.

That is indeed the main advantage of the [] map syntax. And it is a very important one, what with my obsession with small syntaxes. :)

On the other hand, the {} map syntax also has some advantages.

* No potentially weird/unintuitive corner cases when creating an array and converting it to a map
* No issues with exporting variables to other programs
* Easy to implement
* Easy to list the keys 'echo $foo[(seq 1 2 (count $foo))]' and values 'echo $foo[(seq 2 2 (count $foo))]'. This could even be implemented in a shellscript function, so you'd just use 'keys $foo' or 'values $foo'.

I think both syntaxes have merit, and I'd be very happy to see more replys about which syntax other people prefer.

> I don't see how doing this is redundant -- it's just an alternative

Because the main new operation required on a hash is "get keys".  Your
scheme allows this, but rather than "get keys", it only supports "get
keys with values interspersed".  Yes, you could take care of this using
odd-only indexing, but why complicate code that doesn't need to be
complicated?

I'm not sure I see the huge advantage for the [] map syntax here. 'echo $foo' prints all the keys, and 'echo $foo[$foo]' prints all the values. It works, but the latter, while cool, seems somewhat unintuitive. The {} map solution (IMO) just as easy. (See above)

> way of looking at a list -- and in particular I don't see how you
> lose backwards compatibility with the original meaning of an array.
> Anything you could do before with a variable you can still do --
> it's just that you've just been given some new syntax that lets
> you do some new things with a variable that you couldn't do before
> (i.e., look up the values of even elements based on the values of
> odd elements).  In practice a user would normally use a particular
> variable one way or the other,

Right, and that's my point - it's an infrequently used mapping that
doesn't require operator-level support.

I guess the question is if the language becomes larger/more bloated by adding a new operator instead of overloading an existing one.

> but all operations on any variable
> would always make sense and yield reasonably reasonable results.
> (Note that if you wanted to iterate through all the keys or values
> you could just increment your loop counter by 2 instead of 1 --
> although maybe you would also want special functions for extracting
> all the keys or values, again like Perl).  Some things that one

Those special functions are frequent enough to warrant an operator,
whereas the mapping you propose is infrequently used enough to be
implemented as a function instead.

Hadn't really though of that option before. That would remove the need for map functionality from the shell alltogether. But the syntax would be significantly less compact. I'll have to think about how this would look in real code.

> might reasonably do with an array -- such as deleting a single
> element -- would totally redefine the hash lookup.  But as the joke
> goes, if it hurts when you do that, then don't do that!
>
> I'm less optimistic about one thing though.  Originally I thought
> that the hash lookup could at first be implemented by just searching
> an array from beginning to end for a key (which would be a fast
> and easy thing to do), and then at some later date something more
> sophisticated could be done by attaching indexes to a variable the
> first time it was used as a hash, without changing the semantics
> (i.e., the array values would not be scrambled when you used a
> variable as a hash).  I assumed there was some way to do this was
> at least reasonably efficient, even if you didn't end up with the
> the most highly optimized hashes on the market.  But I'm not so
> sure any more, and I suspect that if you want even moderately
> efficient hashes you are going to have to accept that using a
> variable as a hash scrambles the array in some way.  Logically this
> isn't necessary, but in practice it may be, and it detracts from
> the prettiness of the scheme.

I noticed something similar but didn't want to focus on it in my last
response.  Assuming that an index is used, and that the structure is
initially treated as a hash, then when mapping from hash to array, how
is order determined?  Alphabetically?  By time-of-insertion?  By
internal index order?  The answers can be specified, but they're not
necessarily going to be intuitive.

If more speed is desired, then the order must be either arbitrary(hash algorithm) or Alphabetically(Binary search algorithm). The latter should be a reasonable tradeof between inuitivity and speed. It should be possible to use a redblack tree, giving logarithmic performance on all operations. But the initial implementation would probably use time-of-insertion since that is the easiest for a naive implementation.

> I still think it's a good idea
> though; it gives you all the power of Perl hashes, with only one
> variable type and namespace.
>
> Or almost all the power.  Does fish support sparse arrays?  I.e.,
> can you:
>
> set a[1] Hello
> set a[1000] Goodbye
>
> and then use a[500] and a[1500] (returning the value "")?

Did you try it?

Yes, it does, but the missing empty elements are space-separated on
expansion.  Last I looked at the source, fish would internally be
storing 999 ARRAY_SEP characters for the missing elements.

The 'missing' elements become empty elements, i.e. each one of them contains the empty string.

>>[...]
>>
>>>>The advantage to all this is that you don't have to introduce a
>>>>new data type for hashes,
>
>>PHP supports a similar data type to that previously discussed on this
>>list - an array that may be indexed traditionally (numeric keys) or as a
>>hash aka map (string keys) using the same indexing operators [].  This
>>seems to be compatible with the model John suggests for the hash
>>indexing operators {}.
>
> But what if you want to use "1" as a hash key?  Either you need

String "1" is equivalent to integer 1 (in a shell the difference is not
very pronounced anyhow); both are a key that maps to a value.  If
treating the hash as an array, conceptually that key is the first
element, but practically (internal representation) it could be located
anywhere.  Where's the problem?

The problem that I can see is all the potential inconsistency when silently moving from array to map.

>#create array
>set arr foo bar baz
>echo $arr
foo bar baz
>#Use it as a map
>set arr[smurf] blue
>echo $arr
1 2 3 smurf

Not 100% intuitive, IMO.

> some kind of new systax, or you have to accept that some strings
> cannot be used as hash keys.  I think the former is preferable.
--
http://members.dodo.com.au/~netocrat


--
Axel


Isak Savo | 4 Jan 18:53 2006
Picon

Re: I18n support for fish

2006/1/4, Axel Liljencrantz <liljencrantz@...>:
> On 1/4/06, Isak Savo <isak.savo@...> wrote:
> > 2006/1/4, Axel Liljencrantz < liljencrantz@...>:
> > > pretty big change, espacially since gettext doesn't really know how to
> > > handle wide characters.
> >
> > Hmm, are you sure about this? I know I've used UTF-8 as the encoding
> > for the reference language (english) and it works fine. Some of the
> > reference strings contained multibyte characters IIRC. Granted though,
> > I use intltool as a wrapper over gettext so it might apply some magic
> > to make it work.
>
>  I was unclear, but I think what I said was correct. There is a difference
> between wide character strings and multibyte character strings. gettext
> handles multibyte character strings, such as those encoded in UTF-7 and
> UTF-8 just fine. What it doesn't handle, at least not  according to the
> gettext manual or in the latest sources, is _wide_ character strings, i.e.
> strings that use exactly one 4-byte wchar_t character instead of one or more
> 1-byte char characters to encode any single character.

Ok, I understand.

> > >  Read the documentation section on how to do a translation for more info
> on
> > > how to do a translation.
> >
> > I've written a tutorial/introduction about this for the Autopackage
> project:
> >    http://www.autopackage.org/docs/i18n/
> > It's targeted against translating autopackage, but most of it applies
> > to other projects using gettext.
>
>  Very nice. How I wish I'd found your page before I sat down and did all the
> hard work. Would have saved me a bunch of time. I'll add a link to your page
> from the fish homepage in the hope that it will improve your Google-ranking.

:-)

> > GLib (used by GTK) has another solution which prepends the msgid with
> > the context separated by a pipe (|) character:
> >   msgid "Screensaver|Space"
> >   msgstr "Rymd"
> > See
> http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html#Q-:CAPS
>
>  Doesn't that mean you need to provide a special translatiuon for the C
> locale, so that it will output Space instead of Screensaver|Space?

Glib already does that transparently using g_strip_context() on the
returned string if no translation is available (or if it's the C
locale). This is a non-issue however since you won't be using glib.
Just wanted to point out the available solutions.

Isak

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
Isak Savo | 4 Jan 19:02 2006
Picon

using && and || instead of 'and' & 'or'

I'm sorry if this has been discussed before, but it's not easy
searching for this topic in the archives.

What's the position on using && syntax for doing multiple commands
depending on the exit status of the previous. The current usage of
'and'/'or' builtins is awkward at best, kind of reminds me of the old
calculators where you entered the operator first and then the numbers.

It especially makes it hard to nest logic:
    or and make; make install; make clean
vs.
   make && make install || make clean

Keep up the good work. Fish definetly has some good qualities over older shells!

Isak

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
Isak Savo | 5 Jan 12:43 2006
Picon

Re: using && and || instead of 'and' & 'or'

2006/1/5, Axel Liljencrantz <liljencrantz@...>:
> By the way, forgot to say welcome to the fish mailing list. Hi!

Thanks. I hope I'm not stepping on to many toes when I'm coming in as
a newbie and challenges fish design decisions in my first couple of
posts ;-)

> On 1/4/06, Isak Savo <isak.savo@...> wrote:
> > What's the position on using && syntax for doing multiple commands
> > depending on the exit status of the previous. The current usage of
> > 'and'/'or' builtins is awkward at best, kind of reminds me of the old
> > calculators where you entered the operator first and then the numbers.
> >
> > It especially makes it hard to nest logic:
> >     or and make; make install; make clean
> > vs.
> >    make && make install || make clean
>
>  The position is this:
>
>  In retrospect, the RPN notation, i.e. putting the conditional _before_ the
> first operand instead of between them, was a mistake. It will be fixed.
> Possibly in the next version. But soon, at least.

Great to hear!

>  As to using && and || instead of and and or, I am strongly against it,
> since it means that they won't be regular builtins, but instead some kind of
> operators, and I strive for as much syntactic constency as possible. In
> other words, the new syntax will be:
>
>  make; and make install; or make clean

Sounds good. For me, it doesn't really matter if you're using 'and' or
'&&' for logical and, it was the RPN-notation that bugged me most :-)

>  I've been saying this'll be happening 'soon' for about a month, I belive,
> and I still haven't gotten around to it. If that is an acceptable definition
> of 'soon' can be debated.
>
>  Reasons why I feel and is better than &&:
>
>  * Smaller syntax with fewer special syntaxes
>  * Easier to learn if you're new to scripting, since you can find out about
> it through tab completion
>  * The syntax is more closely related to the 'if' syntax

Good points, although the "easier to learn" point is double sided.
Anyone with previous programming/scripting knowledge understands the
'and' operator to be, well, an operator and not a command. Having it
as a builtin makes it inconsistent with most other
scripting/programming languages (which may or may not be a good thing,
depending on your design goals)

I'm biased though, since I'm a big fan of writing series of commands
using && and || on the command line. In a shell script, I guess either
syntax works.

>  The disadvantages are:
>
>  * It's not Posix

This could be a major issue for new fish users coming from
"traditional" shells. Although I totally agree with you that the
POSIX/bash syntax isn't the best and that fish shouldn't try to be
100% POSIX compatible, this is one thing where they got it right.
IMHO.

>  * You have to add an extra ';' before the conditional operator.
>
>  I think all the pros and cons listed above are valid, but the pros, in my
> opinion, outweigh the cons.

Maybe they do, I'm not sure.

Isak

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
Axel Liljencrantz | 5 Jan 17:09 2006
Picon

'and' and 'or' now use infix syntax

Of, I have added a patch to the Darcs version of fish which changes the syntax of 'and' and 'or' to:

make; and make install; or make uninstall

I've also added a patch that gives more helpful error messages when trying to use Posix short circut operators:

axel <at> hellboy ~/c/c/fish_current> pwd || whoami
fish: Expected a command string, got token of type 'Pipe'.
pwd || whoami
     ^
axel <at> hellboy ~/c/c/fish_current> pwd && whoami
~/code/c/fish_current
fish: Expected a command string, got token of type 'Run job in background'.
pwd && whoami
     ^
Job 0, 'pwd &' has ended
axel <at> hellboy ~/c/c/fish_current>

You will notice in the above example that 'pwd && whoami' actually launches 'pwd &' in the background. Maybe fish should do a syntax check on the whole commandline and reject all of it instead?

--
Axel


Gmane