3 ms·

I feel like this would only be useful for badly written software. Anything reliable would check that its operations went through as expected and bail really ea

I feel like this would only be useful for badly written software. Anything reliable would check that its operations went through as expected and bail really early.

millstone 11y ago
Reliable software should definitely check returns codes, but maybe returns success. Inspecting the filesystem to verify the result is overdoing it, and race-y besides.
- emmelaich 11y ago
  It's one of those things that change in tone when expressed in the second or third person. When I do tests, they are the unmistakable sign of good careful programming. When you do tests it's an expression of lack of confidence. Whey they do tests it's a sure sign that really don't know what the hell they're doing. :-) in case it's needed
  - deleted 11y ago
    [deleted]
striking 11y ago
Sometimes you don't have a choice.
tgamblin 11y ago
It's intercepting system calls with ptrace, so it could easily fool the process into thinking its calls did exactly what was expected. A cursory glance through the code indicates that it mostly does. However, it looks like it doesn't record changes to files so that they could be read back in by the application. So this will work for applications that read once and write once, but if the same file is written and read, it'll probably break.
- pablooa 11y ago
  This is what I immediately thought. This command should not be considered fail-proof. Even if you're fooling the caller returning successes when actually doing nothing, the trace displayed by this command can't be considered exactly what the program, running without being traced, would have done.
wingerlang 11y ago
Sometimes I write a script that I am 99% sure that is correct. Let's say I write a regex that should delete files with a specific pattern. With maybe, I could run it and see the files it /actually/ intend to delete with a dry run. I might not want to actually delete them without confirming it.
- HerraBRE 11y ago
  My favourite pattern for this use-case is to write script A that generates script B; instead of A invoking 'rm' directly, it runs 'echo rm', or even 'echo #rm'. Then I open up script B in an editor and review the planned changes. Once I like what I see (potentially after a few edits) I run 'bash B'.

I feel like this would only be useful for badly written software. Anything reliable would check that its operations went through as expected and bail really early.

millstone 11y ago

Reliable software should definitely check returns codes, but maybe returns success. Inspecting the filesystem to verify the result is overdoing it, and race-y besides.

emmelaich 11y ago
It's one of those things that change in tone when expressed in the second or third person. When I do tests, they are the unmistakable sign of good careful programming. When you do tests it's an expression of lack of confidence. Whey they do tests it's a sure sign that really don't know what the hell they're doing. :-) in case it's needed
- deleted 11y ago
  [deleted]

striking 11y ago

Sometimes you don't have a choice.

tgamblin 11y ago

It's intercepting system calls with ptrace, so it could easily fool the process into thinking its calls did exactly what was expected. A cursory glance through the code indicates that it mostly does. However, it looks like it doesn't record changes to files so that they could be read back in by the application. So this will work for applications that read once and write once, but if the same file is written and read, it'll probably break.

pablooa 11y ago
This is what I immediately thought. This command should not be considered fail-proof. Even if you're fooling the caller returning successes when actually doing nothing, the trace displayed by this command can't be considered exactly what the program, running without being traced, would have done.

wingerlang 11y ago

Sometimes I write a script that I am 99% sure that is correct. Let's say I write a regex that should delete files with a specific pattern. With maybe, I could run it and see the files it /actually/ intend to delete with a dry run. I might not want to actually delete them without confirming it.

HerraBRE 11y ago
My favourite pattern for this use-case is to write script A that generates script B; instead of A invoking 'rm' directly, it runs 'echo rm', or even 'echo #rm'. Then I open up script B in an editor and review the planned changes. Once I like what I see (potentially after a few edits) I run 'bash B'.