Skip to content

Conversation

@vicky-dx
Copy link
Contributor

The p8s command was printing space-separated hex bytes, which was not intuitive. Many users expect it to print escaped hex strings like pcs does (e.g., "\x68\x65\x6c\x6c\x6f").

Changes:

  • Changed p8s to call pcs internally
  • Updated help message to clarify p8s is now an alias for pcs
  • Provides more intuitive behavior for creating escaped strings

Before:
p8s 11 → 68 65 6c 6c 6f 20 77 6f 72 6c 64

After:
p8s 11 → "\x68\x65\x6c\x6c\x6f\x20\x77\x6f\x72\x6c\x64"

This makes p8s behave as users naturally expect when looking for escaped hex string output.

Fixes #10058

The p8s command was printing space-separated hex bytes, which was
not intuitive. Many users expect it to print escaped hex strings
like pcs does (e.g., "\x68\x65\x6c\x6c\x6f").

Changes:
- Changed p8s to call pcs internally
- Updated help message to clarify p8s is now an alias for pcs
- Provides more intuitive behavior for creating escaped strings

Before:
  p8s 11  →  68 65 6c 6c 6f 20 77 6f 72 6c 64

After:
  p8s 11  →  "\x68\x65\x6c\x6c\x6f\x20\x77\x6f\x72\x6c\x64"

This makes p8s behave as users naturally expect when looking
for escaped hex string output.

Fixes radareorg#10058
@vicky-dx vicky-dx changed the title Fix #10058 - Make p8s an alias for pcs (escaped hex string) Make p8s an alias for pcs (escaped hex string) Fix #10058 Oct 23, 2025
@trufae
Copy link
Collaborator

trufae commented Nov 1, 2025

im pretty sure i wrote a response for this ticket but seems like i forgot to submit it..

anyway what i wanted to say is that the problem here is that we treat different command suffix in a wrong way. strings are usually determined by:

  • 0 : null byte terminated
  • z : zero terminated string
  • s : string

it feels like p8s should be doing a string.. and this 'spaced' bytepairs seems confusing, so let me think a bit on all those subcommands a little and ill suggest more changes on the p8 subcommands as well as in px

@sagittarius-a
Copy link
Contributor

sagittarius-a commented Nov 5, 2025

Coming from #24791,

I was wondering what was the meaning of a TODO mentioning supporting pq0.

In my understanding, the prefix (pq in my case, p8 here) states the action to perform, i.e printing 8bit hexpair list of bytes. The suffix then acts as a "stopping condition".

So, following this logic, pq0 would mean printing data up to the next null byte, as a QRCode. Then I would expect the p8 command to do the same, which is printing hex bytes.

However, the p8 is using suffix to configure the output format. So the suffix should be treated differently for pq and p8 commands, or more generally, should be different for commands that will have a fixed output format and commands requiring a "stopping condition".


As changing p8s to print escaped hex strings like pcs, my take is: how would you print space-separated hex bytes, as p8s is currently doing? p8s looks the best candidate IMHO. I'd expect something like p8h or p8\ to print as escaped hex strings (like pcs is doing).

I don't know if reaching consistency across all printing commands with suffixes controlling the output format is possible TBH. As long as things are fairly logical/natural I think it's ok, and there will edge cases that will mess up our dream of perfect order.

This was my 2¢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

p8s should do the same as pcs

3 participants