Do they belong to you? Claim these comments.
Nigel Thomas
Is this you? Claim Profile »
1 year ago
in David’s Excellent Adventure on Oracle AppsLab
> official documentation cannot be wiki’ed or democratized because it serves as the warranty for the software.
Sure you don't want the punters messing with the bible, but that doesn't mean you can't surround official documentation with democratized commentary/annotations ... just so long as the difference is clear.
Put your documentation in a searchable format, in bite sized chunks (even chapter by chapter), and it will rise from 4th to 2nd in your list. And help take the strain off your consultants and support (not to mention the customers).
Regards Nigel
Sure you don't want the punters messing with the bible, but that doesn't mean you can't surround official documentation with democratized commentary/annotations ... just so long as the difference is clear.
Put your documentation in a searchable format, in bite sized chunks (even chapter by chapter), and it will rise from 4th to 2nd in your list. And help take the strain off your consultants and support (not to mention the customers).
Regards Nigel
1 year ago
in On handling logging in a script on DanNorris.com
Dan
Another approach (which also works on Windows) is to place the commands you want to log into a bracketed section
(
commands to be logged
more commands to be logged
) > $LOG
This has the added benefit on *nix that you can easily tee and grep the output. So you can log *everything* to a file, but filter out (say) significant progress and error messages. I tend to start my messages with == (the more equals signs, the more important) and then you can filter messages by how many == they have:
(
commands
) | tee $log | grep "^==="
Of course on *nix you can also redirect stderr at the same time in the usual way(s) eg:
(
commands
) >2&1 >$LOG
I think using brackets (braces) like this is easier to read - and you can nest the brackets too. Just make sure you match brackets properly.
Regards Nigel
Another approach (which also works on Windows) is to place the commands you want to log into a bracketed section
(
commands to be logged
more commands to be logged
) > $LOG
This has the added benefit on *nix that you can easily tee and grep the output. So you can log *everything* to a file, but filter out (say) significant progress and error messages. I tend to start my messages with == (the more equals signs, the more important) and then you can filter messages by how many == they have:
(
commands
) | tee $log | grep "^==="
Of course on *nix you can also redirect stderr at the same time in the usual way(s) eg:
(
commands
) >2&1 >$LOG
I think using brackets (braces) like this is easier to read - and you can nest the brackets too. Just make sure you match brackets properly.
Regards Nigel