Several Bugfixes for Solaris (patch included)

[GoogleCodeExporter]

Yeah, I know... Solaris.  The good news is I'm using this script to help retire 
the systems rather than adding new ones.

The attached patch fixes some bugs but introduces a dependency on perl.  I 
think the simple code I used will work on perl4 or better, so even ancient Sun 
systems should be able to handle it.

These bugs are fixed in the patch:

1) On Solaris, the braindead sed doesn't understand [:alnum:], so I use perl 
instead (on all platforms).  Perl has been in common usage for over 10 years, 
so this isn't as horrible a dependency as it might have been in 1999 or so.  :-)

2) "ps" on Solaris uses slightly different syntax for ps, so I created a 
Solaris-only section with the correct syntax ("comm" vs. "command" and "-e" 
instead of "a")

3) When recursion was disabled, the script would abort with a find syntax 
error, even on Linux.  On Linux, I think you meant to use "-maxdepth 1" instead 
of "-depth 1" (-depth doesn't take an argument.)  To make this portable to 
Solaris, I used a nasty hack involving -prune instead.  This also works on 
Linux, so I didn't make it $ARCH-dependent.

4) Solaris' /usr/bin/grep is broken.  Grep?  Really?  Yes.  Still, it's better 
than HP-UX's grep-- at least it can combine -E and -i, once the right grep is 
used.  I added an $ARCH-dependent section to use /usr/xpg4/bin/grep instead.  
There are a couple other greps in other paths that would probably also work, 
but this was the path listed in the man page and it works.

5) ETA date was broken on Solaris.  Since I'd already used perl for the sed 
fix, I just went back to it since it handles "system" time well.

6) Since I'd already included perl, I changed out the clever but dirty truss 
hack to get the system date with a simple perl command.  See #5.

Note: In the SVN code it appears that you've changed to only using the MD5 hash 
instead of the filename.  While I understand how this makes it simpler, please 
make it optional.  If I'm processing multi-gigabyte files, the last thing I 
want is to be forced to wait for an md5 digest to complete just to easily name 
a logfile.  :-)

  -- Steve Bonds

Original issue reported on code.google.com by sbo...@gmail.com on 10 Mar 2012 at 5:07

Attachments:

• ppss.swbonds.patch

[GoogleCodeExporter]

Thank you - I'll try to review and update PPSS as soon as possible.

Original comment by Louwrentius on 12 Mar 2012 at 9:39

[GoogleCodeExporter]

If I'm correct, the unique name (a string) of the file is hashed, not the file 
itself so multiple gig files should not be an issue whatsoever. Do you agree?

Original comment by Louwrentius on 12 Mar 2012 at 9:41

[GoogleCodeExporter]

You're right.  The code says "echo", my brain says "cat".  This is just a hash 
of the pathname which shouldn't be too terribly CPU-intensive.  :-)

Original comment by sbo...@gmail.com on 12 Mar 2012 at 10:07

[GoogleCodeExporter]

In SVN, I have a ppss-test.sh suite, run it with ./ppss-test.sh debug to get 
the actuall output results. 

It shows that the NoRecursion tests fails.

Your version does not pick up some files somehow. 

Wrong:

{{{
/tmp/ppss/root/file-1
/tmp/ppss/root/file-10
/tmp/ppss/root/file-2
/tmp/ppss/root/file-3
/tmp/ppss/root/file-4
/tmp/ppss/root/file-5
/tmp/ppss/root/file-6
/tmp/ppss/root/file-7
/tmp/ppss/root/file-8
/tmp/ppss/root/file-9
}}}

Correct:

{{{
/tmp/ppss/root//file-1
/tmp/ppss/root//file-10
/tmp/ppss/root//file-2
/tmp/ppss/root//file-3
/tmp/ppss/root//file-4
/tmp/ppss/root//file-5
/tmp/ppss/root//file-6
/tmp/ppss/root//file-7
/tmp/ppss/root//file-8
/tmp/ppss/root//file-9
/tmp/ppss/root//hosts
/tmp/ppss/root//resolve.conf
}}}

I do not understand why this is the case and I don't have Solaris anywhere 
around here. 

Original comment by Louwrentius on 17 Mar 2012 at 8:34

[GoogleCodeExporter]

It looks like SVN is missing the "shunit2" script called by the test.  Is that 
intentional?  I'm also not sure where the assertEquals function is defined.

The problem with the find is that it looks like the skipped items are symlinks. 
 The Solaris-compatible find command would include a symlink to a directory as 
a file to process, so it's only looking for files of "-type f".

The original -maxdepth 1 command also does this, so to simulate the original 
output just change the lines like:

$(exec_cmd "find \"$SRC_DIR\" ( ! -name \"$_dir_basename\" -o -type f ) -prune 
-type f -print" > "$LISTOFITEMS")

to (change the final "-type f" to "! -type d"):

$(exec_cmd "find \"$SRC_DIR\" ( ! -name \"$_dir_basename\" -o -type f ) -prune 
! -type d -print" > "$LISTOFITEMS")

Of course, you may not want to include symlinks to directories as files to 
process.  :-)

Original comment by sbo...@gmail.com on 18 Mar 2012 at 5:27

[GoogleCodeExporter]

Ah right, I look into this. thanks.

Original comment by Louwrentius on 20 Mar 2012 at 1:54

[GoogleCodeExporter]

I incorporated the proposed fixes in SVN. I also included shunit2 for 
convenience. I tested your solution and it worked on Mac OS X Lion again. After 
that, I added if-statements to only use this trick if Solaris is detected. Not 
all that clean, but I can live with that. If there are any issues, I'd like to 
know. Thanx!

Original comment by Louwrentius on 24 Mar 2012 at 9:15