PARGS(1)

💖 NAME 💖

pargs — bestie, this is the tool that prints a process's arguments, its environment variables, or its auxiliary vector. That's it. That's the whole job. And it ate. 💅

---

✨ SYNOPSIS ✨

pargs [-l] [-a|--args] [-e|--env] [-x|--auxv] [pid | core]...

---

🦋 DESCRIPTION 🦋

okay so picture this: you've got a target process, or a process core file, and you want the tea. pargs peeks inside and prints out the arguments, the environment variables and their values, or the process auxiliary vector. 👑

For live processes, the arguments and environment variables are read straight out of process memory, which means you're seeing the current state — including anything that got modified at runtime. Yes, like when someone calls setenv(3), or just straight-up overwrites argv. 😌

And this is the part that's giving different energy from /proc/pid/cmdline and /proc/pid/environ, because those two are just static snapshots frozen at process start. No updates. No growth. Just vibes from the past. Meanwhile pargs is live, current, in the group chat right now. 📲

Also! Two little twins you should know about:

• The pauxv command is literally equivalent to running pargs(1) with the -x option.
• The penv command is literally equivalent to running pargs(1) with the -e option.

Periodt. 💖

---

🎀 OPTIONS 🎀

• -l — prints the arguments as one single command line. The way it's printed is suitable for interpretation by /bin/sh, so it's copy-paste-into-your-shell friendly. iconic behaviour honestly. 🐚
• -a, --args — print the process arguments. This is the default btw, in case you were wondering. For live processes, these are read from process memory and reflect the current values. 💫
• -e, --env — print the process environment variables and their values. For live processes, the environment is read from process memory via the environ symbol, and it reflects runtime changes made with setenv(3) or putenv(3). so if somebody changed it, you'll see it. 🔍
• -x, --auxv — print the process auxiliary vector exactly as contained in /proc/pid/auxv. 🧚

---

🌸 OPERANDS 🌸

• pid — a Process ID list. You can also pass a /proc/pid path instead, which means shell expansions like /proc/* will target all processes on the system. Go off, glob. 🌈
• core — a process core file, as produced by systemd-coredump(8), or an Ubuntu/Debian apport .crash file. For systemd core files, the file does not need to exist on disk — if it's been removed, the corresponding systemd journal entry gets used instead. Check the NOTES below for the whole story. 👀

---

💀 EXIT STATUS 💀

• 0 on success 🎉
• non-zero if an error occurs — like no such process, permission denied, or an invalid option. sad but true. 😭

---

🍓 FILES 🍓

• /proc/pid/* — process information and control files. the source of truth, the archives, the lore. 📁

---

🧚 NOTES 🧚

So here's the situation, bestie. When a core file has been removed by systemd-tmpfiles(8), or by storage limits configured in coredump.conf(5), the systemd-coredump(8) journal entry for the crash may still be available. In that case you can pass the path to the deleted core file as the core operand — even though the file no longer exists on disk — and the process metadata will be retrieved from the journal entry instead. ✨

Want the path of a missing core file? Use coredumpctl(1), like this:

coredumpctl list <name> -F COREDUMP_FILENAME

Ubuntu/Debian apport .crash files are supported too 🫶. These files use Debian control syntax with base64-encoded gzip core dumps. Text fields — such as ProcCmdline, ProcEnviron, and ExecutablePath — are mapped to COREDUMP_* fields, and the core dump is extracted on first access. lowkey magic. 🪄

---

👑 SEE ALSO 👑

pauxv(1), penv(1), coredumpctl(1), proc(5)

---

okay that's the whole page, you're so welcome 💜 this was pargs 0.2.23, from September 2026 — go read a process's whole diary, bestie, it's your moment. 🎀✨