Skip to content

Unexpected token parsing statement '=' #114

Closed

Description

@katcipis

The line that generates this is:

volumes <= docker volume ls -qf dangling=true

I'm not sure if there is an error on this, the command on the right side of the statement is a valid shell command, should I quote it ?

Also I'm a little worried because an error on a alias aborted nash, If i place it as my default shell (as I intend to) if I make some mistake on an alias it will stop to start when I login on the machine. It would be good to know that one of the aliases broke, but aborting seems a little extreme on this case. When executing other types of automation this seems great, but as the default shell that is loaded when I run nash it really seems extreme.

Activity

  1. i4ki commented on Oct 1, 2016

    @i4ki
    Collaborator

    Currently, on nash you need to quote every argument that uses '=', but I'm not sure if it's the best behaviour..
    The reason is to avoid the ambiguity below:

    ls = "a"

    The statement above must be interpreted as a variable assignment (LS EQUAL A) or as a command execution (CMD[ls] ARG[=] STRING[a]) ?

    Currently the command is a variable assignment.

    λ> ls = "a"
    λ> echo $ls
    a
    λ> touch "=" a
    λ> ls "=" a
    '='  a
  2. i4ki commented on Oct 1, 2016

    @i4ki
    Collaborator

    About the second problem related to nash aborting execution on first error found, as you know, this is required for nash scripts, but today nash works the same way (at least very close) when executed interactive and as script.

    If you made some mistake on your init, you can start nash with "-noinit" parameter to start it fresh. What do you think? Solves the problem?

  3. katcipis commented on Oct 2, 2016

    @katcipis
    MemberAuthor

    How does shell solve this ? I think it works on shell/bash.

    About running with -noinit, it actually wont work. An error on that nature will make you unable to log in your machine depending on the distro, fixing it is not rocket science, but it is also not fun and pleasant :-).

    I understand the beauty in letting it symmetric with how scripts are executed, but I'm a little torn with the aggressive behavior on failure when using as a interactive shell (and understanding a little better the bash behavior also :P)

  4. i4ki commented on Oct 4, 2016

    @i4ki
    Collaborator

    bash/posix shells are bizarre:

    [i4k@johncarter ~]$ ls = "a"
    ls: cannot access '=': No such file or directory
    ls: cannot access 'a': No such file or directory
    [i4k@johncarter ~]$ ls="a"
    [i4k@johncarter ~]$ echo $ls
    a
    [i4k@johncarter ~]$
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions