Hello Kevin,
Thank you for taking the time to write this up! Your git script looks very
ambitious, and so this is thoughtful, informed feedback. (Incidentally I just
merged your git script changes). Let me respond to each point in turn:
1.2. 3.: Regarding string manipulation: I'm in favor of doing something here,
as long as it keeps in fish's spirit. i.e. definitely do NOT adopt the POSIX
specification for variable modifiers, like ${a##*/} to strip all leading path
components from $a. That's just line noise, and we can do way better.
I also like your suggestion of supporting "$(…)", especially because this is
currently a syntax error, so there's no compatibility risk. There's some
synergy between this and string manipulation. There could be a built-in "str"
or "munge" or whatever that manipulates its argument based on other parameters,
e.g. "(munge --strip '/*' --repeat $PWD)" to get the last component of pwd.
But we ought not to invent yet another string manipulation syntax. If anyone
has any suggestions for an existing command-based string manipulation syntax
that would be appropriate for fish, please share it.
4. Can you elaborate on your math needs? Farming out to bc is slow, but I
haven't encountered a case where it matters.
5. Extending builtin test with == for globbing seems reasonable; currently ==
is a syntax error. Mapping [ to built-in test seems good too. Introducing [[ is
bad: [[ does some very magical things to its arguments (like not expanding
them) that can't be handled generically.
6. Agreed regarding 'else if'. Any objection to 'elif' as seen in bash, Python,
and others?
7. I see your point regarding the difficulty of doing an assign-and-test, but
the construct
if set foo (some command)
…
appears to be checking the success of the set command, not of the subcommand.
Still I don't have any better suggestions - that's one to think about.
_fish
On Jun 21, 2012, at 10:58 AM, Kevin Ballard wrote:
> During the process of porting __git_ps1 to Fish (see my previous email), I ran
> into lots of issues (both design issues and missing functionality) with Fish
> scripting. I've already filed issues for a lot of these, but I thought I would
> just try to round them all up. These are in no particular order:
>
> 1. Fish seriously needs some facility for doing basic string manipulation.
> Farming out to other processes is rather slow and complicated. In fact, when I
> needed to replicate bash's functionality for "${somevar#strip/prefix}", it
> turned out the easiest way to do that was in fact to use bash again, with
> (/bin/sh -c 'echo ${1#strip/prefix}' -- $somevar). Farming out to other
> programs
> to do work, as slow as it is, is at least understandable, but having to
> actually
> farm out to bash itself seems completely wrongheaded.
>
> 2. Fish could really use an equivalent for bash's ${var:-value} syntax. It's
> very awkward to turn what could be one expression into 4 lines is rather
> awkward. And in fact in my __fish_git_prompt script, the lack of this
> functionality ballooned into a lot more work because I didn't want to insert
> those 4 lines everywhere I needed the simple characters. See the
> __fish_git_prompt_validate_chars function from my __fish_git_prompt.fish
> script,
> along with the extra event handler to invalidate those variables. This
> functionality could have been used to simplify the color variable logic as
> well.
>
> 3. Fish needs a way to do command substitution within a double-quoted string.
> The simplest solution is probably to support $() within double-quotes. The
> reasoning is twofold: first, a command substitution that evaluates to no
> output
> ends up being stripped entirely from the argument list of its surrounding
> command. This has extremely bad implications when using it with, e.g. `test -n
> (some command)`. Second, this would allow for storing the output with its
> newlines in a variable, instead of having the output be split into multiple
> elements. And as a bonus it would make it a lot easier to combine command
> substitution output with other text in the same argument, e.g. "$somevar"(some
> command)"$anothervar".
>
> 4. Fish needs basic math. Farming math out to `bc` is extremely slow.
>
> 5. Fish needs a way to do string testing with pattern matching, e.g. the ==
> operator from bash's [[ builtin.
>
> 6. We need 'else if'. I can't figure out why that was omitted.
>
> 7. A command substitution should be allowed to modify the $status of its
> surrounding context. It's currently documented as not touching $status,
> although
> this documentation is fairly unnecessary because if it did modify $status,
> that
> would simply be overwritten by the status of the command that it's being
> passed
> as an argument to. However, once command substitution can modify $status, then
> the next step is to modify the `set` builtin to not modify $status unless the
> `-q` flag was provided. With both of these changes, I can then store the
> command
> output into a variable and act on its status. In bash, this is trivial:
>
> if foo="$(some command)"; then
> # the command substitution exited 0
> fi
>
> In Fish, I'd really like to be able to say
>
> if set foo (some command)
> # the command substitution exited 0
> end
>
> Instead I have to use the awkward construct
>
> set -l oldStatus
> set foo (some command; set oldStatus $status)
> if test $oldStatus -ne 0
> # the command substitution exited 0
> end
>
> -Kevin
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Fish-users mailing list
Fish-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fish-users
