Update linux_procmemdump.sh

[Pierre-Gronau-ndaal]

replaced some stuff like echo with printf
restrict error handling
etc …

[tclahr]

After some tests I noticed it is failing to collect the sections/maps after the changes. Can you test the following, please?

sudo ./linux_procmemdump.sh -u -b -d proc

[tclahr]

What system are you using for testing it? Here it is still failing to collect the memory sections.

[takusuman]

Hi, I know I'm new here, but I have some points to talk about.

replaced some stuff like echo with printf

O.k., great, but look: was there a real necessity of replacing echo? I know the "printf(1) command vs echo built-in" argument doesn't apply here because, well, this run on the GNU Bash, and both are implemented as built-ins with extensions, but it's more of a formality: was it really needed? Hasn't anything garbled because of this change? Sometimes, when strings aren't properly quoted, printf will mess things up and, if it worked before and it was present on critical points of the code, changing it maybe wasn't a good idea.

Now this caught my attention:

-- mkdir -p "${outputdir}"
++ sudo mkdir -p -v "${outputdir}"

Not every machine has sudo, this would add another dependency that wouldn't be necessary if you were using the program correctly. Also, although I can recognize that verbose is cool, not every system has a mkdir with a -v flag --- and that applies to modern systems as well, not everyone has bowed to BSD/GNU standards (even though additions like this are useful). Again, this will break compatibility.

I saw that you've implemented a function called dump_memory(); it seems a nice addition, but why are you declaring it inside a while loop and not outside it? I'm not judging it, I just want to comprehend it better.

In any case, this will need some fixes to be merged. If I were you, I would have this as a draft pull-request to work in until it gets ready to be reviewed and merged.

[Pierre-Gronau-ndaal]

Hi, I know I'm new here, but I have some points to talk about.

replaced some stuff like echo with printf

O.k., great, but look: was there a real necessity of replacing echo? I know the "printf(1) command vs echo built-in" argument doesn't apply here because, well, this run on the GNU Bash, and both are implemented as built-ins with extensions, but it's more of a formality: was it really needed? Hasn't anything garbled because of this change? Sometimes, when strings aren't properly quoted, printf will mess things up and, if it worked before and it was present on critical points of the code, changing it maybe wasn't a good idea.

Now this caught my attention:

-- mkdir -p "${outputdir}"
++ sudo mkdir -p -v "${outputdir}"

Not every machine has sudo, this would add another dependency that wouldn't be necessary if you were using the program correctly. Also, although I can recognize that verbose is cool, not every system has a mkdir with a -v flag --- and that applies to modern systems as well, not everyone has bowed to BSD/GNU standards (even though additions like this are useful). Again, this will break compatibility.

I saw that you've implemented a function called dump_memory(); it seems a nice addition, but why are you declaring it inside a while loop and not outside it? I'm not judging it, I just want to comprehend it better.

In any case, this will need some fixes to be merged. If I were you, I would have this as a draft pull-request to work in until it gets ready to be reviewed and merged.

sorry about my bugs!

hints to echo vs printf

## POSIX Comparison: `echo` vs `printf`

### Overview

Both `echo` and `printf` are used to output text in shell scripts, but they differ significantly in **portability**, **predictability**, and **POSIX compliance**.

---

### POSIX Compliance and Portability

| Feature               | `echo`                                             | `printf`                                 |
|-----------------------|----------------------------------------------------|------------------------------------------|
| **POSIX Standard**    | Loosely defined; behavior varies                   | Strictly defined and consistent          |
| **Options**           | Handling of options (e.g., `-n`, `-e`) is implementation-defined | No options; format string required       |
| **Escape Sequences**  | Handling is not standardized; may require `-e` or be unsupported | Well-defined (e.g., `\n`, `\t`, etc.)   |
| **Output Consistency**| Varies between shells and systems                  | Consistent across POSIX systems          |
| **Suppress Newline**  | `-n` flag (not always portable)                    | Omit `\n` in format string               |

---

### Key Differences

#### `echo`
- **Not fully standardized**: Different shells and systems interpret `echo` flags and escape sequences differently.
- **Ambiguity with input**: If the string starts with `-`, it may be treated as an option.
- **Escape sequences**: Some require `-e` to interpret escapes, others do not; some do not support escapes at all.
- **Portability**: Only reliably outputs plain text without options or escapes.
- **Use case**: Suitable for simple, controlled output where portability is not a concern.

#### `printf`
- **Strictly POSIX-compliant**: Format and behavior are well-defined by POSIX.
- **No ambiguity**: Always interprets the first argument as a format string, so values starting with `-` are not problematic.
- **Predictable escape handling**: Recognizes standard C-style escapes in the format string.
- **Suppressing newline**: Simply omit `\n` from the format string.
- **Portability**: Preferred for scripts intended to run on any POSIX-compliant system.
- **Use case**: Recommended for all scripting where output may include variables, special characters, or needs to be portable.

---

### Practical Examples

#### Printing a variable that may start with `-` or contain backslashes

Using echo (unreliable)

echo "$var"

Using printf (reliable)

printf '%s\n' "$var"

#### Printing without a trailing newline

echo (may not be portable)

echo -n "No newline"

printf (portable)

printf '%s' "No newline"

---

### Summary Table

| Aspect                | `echo`                                 | `printf`                          |
|-----------------------|----------------------------------------|-----------------------------------|
| Portability           | Poor for complex cases                 | Excellent                        |
| Predictability        | Low (varies by implementation)         | High (POSIX-defined)              |
| Escape Handling       | Unreliable                             | Reliable, C-style                 |
| Suppress Newline      | `-n` (not portable)                    | Omit `\n` in format string        |
| Formatting            | None                                   | Extensive (width, precision, etc) |

---

### POSIX Recommendation

> **POSIX explicitly recommends using `printf` instead of `echo` for portable scripts, especially when outputting variables or handling special characters.**

---

### Conclusion

- **Use `printf` for scripts that require portability, reliability, and precise formatting.**
- **Reserve `echo` for very simple, controlled cases where you are certain of the environment and input.**

This approach ensures your scripts behave consistently across all POSIX-compliant systems.

[takusuman]

sorry about my bugs!

No problem, just take care of them and inquire for help if necessary.
Summarizing my text above, again: why is dump_memory declared inside the while loop? And the sudo program call? -v option on mkdir, etc, etc, etc, etc.

hints to echo vs printf

I know about these problems, but thanks for clarifying. I just questioned about how these problems happened in the code, I hadn't seen any complaint about it before.
Also, please, avoid using A.I. for writing things that you can explain in a paragraph. I have an impression that people will forget how to properly write documentation if this "A.I. writing mania" continues as it is, and I also think some projects consider it spam.
I don't want to sound surly per any means, but that's is it.