All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Ohly <patrick.ohly@intel.com>
To: bitbake <bitbake-devel@lists.openembedded.org>
Subject: shell parser: deep nesting
Date: Fri, 18 Nov 2016 16:22:09 +0100	[thread overview]
Message-ID: <1479482529.27625.76.camel@intel.com> (raw)

Hello!

I ran into a bug
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=10668) where parsing
a shell fragment like "echo hello & wait $!" triggers this error:

Traceback (most recent call last):
  File "/work/poky/bitbake/lib/bb/codeparser.py", line 400, in ShellParser.process_tokens(tokens=[('if_clause', <bb.pysh.pyshyacc.IfCond object at 0x7fb480963390>)]):
                 if more_tokens:
    >                self.process_tokens(more_tokens)
     
  File "/work/poky/bitbake/lib/bb/codeparser.py", line 400, in ShellParser.process_tokens(tokens=<itertools.chain object at 0x7fb480949278>):
                 if more_tokens:
    >                self.process_tokens(more_tokens)
     
  File "/work/poky/bitbake/lib/bb/codeparser.py", line 400, in ShellParser.process_tokens(tokens=[('while_clause', <bb.pysh.pyshyacc.WhileLoop object at 0x7fb480949518>)]):
                 if more_tokens:
    >                self.process_tokens(more_tokens)
     
  File "/work/poky/bitbake/lib/bb/codeparser.py", line 400, in ShellParser.process_tokens(tokens=<itertools.chain object at 0x7fb480446668>):
                 if more_tokens:
    >                self.process_tokens(more_tokens)
     
  File "/work/poky/bitbake/lib/bb/codeparser.py", line 393, in ShellParser.process_tokens(tokens=[[('pipeline', <bb.pysh.pyshyacc.Pipeline object at 0x7fb480949c88>)]]):
             for token in tokens:
    >            name, value = token
                 try:
ValueError: need more than 1 value to unpack

After thinking about this a bit more I *think* I understand the problem
(expecting a certain level of nesting while the parser may also hand out
tokens with deeper nesting in the pipeline case) and I'll send a patch
fixing the issue for me.

But I'm not entirely sure whether that's really addressing the root
cause of the problem - perhaps such deep nesting shouldn't occur?

So I hope that someone familiar with this code can have a look at the
problem and the proposed solution.

Also, does it have performance implications that
ShellParser.process_tokens() defines the same helper functions
repeatedly? They don't depend on the current invocation context and thus
could also be defined as private helper functions in ShellParser.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





             reply	other threads:[~2016-11-18 15:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-18 15:22 Patrick Ohly [this message]
2016-11-18 15:23 ` [PATCH] codeparser.py: support deeply nested tokens Patrick Ohly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1479482529.27625.76.camel@intel.com \
    --to=patrick.ohly@intel.com \
    --cc=bitbake-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.