Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bashlex.errors.ParsingError that occurs when the gptme tool; an unexpected newline character ('\n'). - bug #55

Closed
nslieske opened this issue Dec 10, 2023 · 3 comments
Labels
bug Something isn't working tool

Comments

@nslieske
Copy link

nslieske commented Dec 10, 2023

I found this bug and used gptme to give a summary at the end. Please let me know if this is a good way to report bugs and if there is anything I can do to improve on the reporting process.

Thanks

noah@n:~$ cat gptmebug.txt 
user@debian:~$ .local/bin/gptme
WARNING:gptme.tools.python:Missing packages: numpy, pandas, matplotlib. Install them with `pip install gptme-python -E datascience`

Using logdir /home/user/.local/share/gptme/logs/2023-12-10-singing-red-starfish
Skipped 1 hidden system messages, show with --show-hidden
--- ^^^ past messages ^^^ ---
User: what does a red D mean in the htop command in status colum
Assistant: The `D` status in the `htop` command output stands for "Disk Sleep". It means that the process is in an uninterruptible sleep state. This is usually caused by the process waiting for an I/O operation to complete. 

In other words, the process is waiting for data that isn't in memory to be loaded from disk into memory. This could be due to a slow disk or a large amount of data being read. 

It's important to note that a process in `D` state cannot be interrupted or killed until it comes out of this state, even by signals like `SIGKILL` or `SIGSTOP` that normally have the power to terminate or pause any process.                                                                                                                                  User: how do we make sure that process is not dead?
Assistant: To ensure that a process is not dead, you can use the `ps` command with the process ID (PID). The `ps` command provides information about the currently running processes, including their PIDs.

Here's how you can use it:

```bash
ps -p <PID>
```



                                                                                                                                                                                 
Preview
$ ps -p <PID>                                                                                                                                                                    

 ⚠️ Execute code? (Y/n)  
Traceback (most recent call last):
  File "/home/user/.local/bin/gptme", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
         ^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/gptme/cli.py", line 168, in main
    chat(
  File "/home/user/.local/lib/python3.11/site-packages/gptme/cli.py", line 239, in chat
    for msg in loop(log, no_confirm, model, stream=stream):  # pragma: no cover
  File "/home/user/.local/lib/python3.11/site-packages/gptme/cli.py", line 293, in loop
    yield from execute_msg(msg_response, ask=not no_confirm)
  File "/home/user/.local/lib/python3.11/site-packages/gptme/tools/__init__.py", line 29, in execute_msg
    yield from execute_codeblock(codeblock, ask)
  File "/home/user/.local/lib/python3.11/site-packages/gptme/tools/__init__.py", line 42, in execute_codeblock
    yield from execute_shell(codeblock_content, ask=ask)
  File "/home/user/.local/lib/python3.11/site-packages/gptme/tools/shell.py", line 143, in execute_shell
    returncode, stdout, stderr = shell.run(cmd)
                                 ^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/gptme/tools/shell.py", line 38, in run
    commands = split_commands(code)
               ^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/gptme/tools/shell.py", line 206, in split_commands
    parts = bashlex.parse(script)
            ^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/bashlex/parser.py", line 610, in parse
    parts = [p.parse()]
             ^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/bashlex/parser.py", line 691, in parse
    tree = theparser.parse(lexer=self.tok, context=self)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/bashlex/yacc.py", line 537, in parse
    tok = self.errorfunc(errtoken)
          ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/user/.local/lib/python3.11/site-packages/bashlex/parser.py", line 548, in p_error
    raise errors.ParsingError('unexpected token %r' % p.value,
bashlex.errors.ParsingError: unexpected token '\n' (position 11)
user@debian:~$ 


Assistant: The error message you're seeing is a `bashlex.errors.ParsingError`, which is raised when the `bashlex` library encounters a token it doesn't expect while parsing a bash script. In this case, the unexpected token is a newline character (`'\n'`).

This error is occurring in the `gptme` tool, which is a command-line interface (CLI) tool that uses the `bashlex` library to parse and execute bash commands. It seems that `gptme` is trying to parse a bash command, but it's encountering a newline character where it doesn't expect one, causing the parsing to fail.

To resolve this issue, you would need to identify the bash command that's causing the error and correct it. The error message doesn't provide enough information to identify the exact command that's causing the problem, but it's likely that there's a syntax error in the command.

If you're writing a bash script, make sure that all commands are correctly formatted and that there are no unexpected newline characters. If you're entering commands directly into the `gptme` tool, make sure that you're following the correct syntax for each command.                                                                                        User:      


Assistant: The bug is a `bashlex.errors.ParsingError` that occurs when the `gptme` tool, a command-line interface (CLI) tool, is trying to parse and execute bash commands. The error is caused by an unexpected newline character (`'\n'`). This suggests that there's a syntax error in the bash command being parsed, possibly an unexpected newline character in a place where it shouldn't be. The exact command causing the error isn't specified in the traceback. The solution would involve identifying and correcting the problematic bash command.
User:
@nslieske
Copy link
Author

gptmebug.txt

@nslieske nslieske changed the title bashlex.errors.ParsingError that occurs when the gptme tool; an unexpected newline character ('\n'). bashlex.errors.ParsingError that occurs when the gptme tool; an unexpected newline character ('\n'). - bug Dec 10, 2023
@ErikBjare
Copy link
Owner

ErikBjare commented Jan 20, 2024

This happens when it tries to run a command with <PID> since it then expects an output file to pipe to.

I should add a test case for this, and make sure it gives an appropriate error that we catch (along with any other tool-related exceptions) and return to the conversation so the LLM can see the oopsie.

I also think gptme needs a better way to let the LLM communicate "this is just an example, we do not mean to run it".

@ErikBjare
Copy link
Owner

I fixed so that the error is handled more gracefully in becab4d

Tracking the more fundamental UX issue about examples vs runnable code in #67

Thanks for reporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working tool
Projects
None yet
Development

No branches or pull requests

2 participants