Apologies for the complications that this interactive shell provides here. These problems didn't arise previously primarily because the interactive shells were designed to receive commands, give you the raw output, and then the developer extract specifically what they want from the output and ignore the things they don't. I understand however that in your case it might be beneficial to just consume everything. Some of these changes seem universally good and overall not harmful to include (like removing the trailing prompt, I can't really see a use for it) but some others come with caveats, so if it is too complicated this might be better to handle as something testpmd specific, and leave the generic interactive shell to always just give you raw output.
On Wed, Apr 17, 2024 at 9:18 AM Juraj Linkeš <juraj.lin...@pantheon.tech> wrote: <snip> > > >> @@ -132,6 +135,9 @@ def send_command(self, command: str, prompt: str | > > >> None = None) -> str: > > >> self._stdin.flush() > > >> out: str = "" > > >> for line in self._stdout: > > >> + if skip_first_line: > > >> + skip_first_line = False > > >> + continue > > > > > > Is there ever a reason to distinguish between the first line and the > > > line with the command on it? > > > > As above, not really sure. Would this always be a command prompt? The Whether this first line is always the command prompt or not is specific to the shell unfortunately. In "bash-like" shells where commands you send are echoed into stdout for easy-of-use for the developer (like testpmd), this first line will always be the command you sent to it. It technically isn't always required for this to happen however, so we could make this assumption, but it could be slightly more limiting down the line. > > doubt arises only because I don't understand why we'd need the command > > prompt fed back. > > > > The only thing I could think of is debugging. Maybe it could offer > some extra insight in some corner cases. I agree that it is useful for debugging, but we do also log it separately before sending the command. I don't think the command could change by simply being sent into the shell unless something strange happens like the shell breaks it across multiple lines. I think it would be fine to exclude it, but as mentioned, it isn't always safe to do so. > > > > > > >> if prompt in line and not line.rstrip().endswith( > > >> command.rstrip() > > >> ): # ignore line that sent command > > >> -- > > >> 2.34.1 > > >> > >
