Brian Wright

Here's a very basic way to do what you're looking for, I think. Note that there are a horde of ways to do this, I was just looking for something fairly easy to follow:

===========================================================
#!/usr/bin/ksh
LATEST=$(ls -1t backup*.zip | head -1 | cut -d. -f1 | sed "s+backup++g")

if [[ ${LATEST} -eq 50 ]]
then
LATEST=0
fi

NEW=$(( ${LATEST} + 1 ))


BACKUP_FILENAME="backup${NEW}.zip"
===============================================================

Hope this gives you something to play with!

This is clearly only a code segment, but here's a basic analysis of what it's apparently trying to do. It would be easier if the output of the script were given - this script has a lot of debug information in it which will really help you. This script segment is carrying out a three-part if-statement as follows:

A)
if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
(eval $ac_compile) 2>conftest.er1
ac_status=$?
grep -v '^ *+' conftest.er1 >conftest.err
rm -f conftest.er1
cat conftest.err >&5
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); }

This section is actioning the $ac_compile command, defined elsewhere in the script. This section creates the error file 'conftest.err' which it displays to output redirection channel 5 and returns the exit code of the $ac_compile command IE if the compile succeeds return TRUE - we'll call this answer A.

&& (This is a perhaps best considered a connective AND in the overall 'if' statement.)

B)
{ ac_try='test -z "$ac_cxx_werror_flag"
|| test ! -s conftest.err'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); }; }

This section checks to see if the string $ac_cxx_werror_flag is zero length OR if the file conftest.err (created in section A) does not exist or is empty. This section returns the result of the two tests within this section IE if the flag variable is zero length or the file either doesn't exist or it is empty, return TRUE. This is answer B


&& (Again we have an 'AND' statement in the main three-part IF statement.)

C)
{ ac_try='test -s conftest.$ac_objext'
{ (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
(eval $ac_try) 2>&5
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); }; }

This segment tests to see if the file conftest.$ac_objext exists and is non-zero in size. We'll call this answer C.

So - at this point we have three possible failure points. The script is using the following logic:

If (answer A=TRUE) AND (answer B=TRUE) AND (answer C=TRUE) then (carry on) else (display error messages)

The output from your script should show pretty clearly what it's trying to do and the point at which it failed. Check for the destination of output redirection on channel 5 (the >&5), as that's where the debug information is going.


Anyway, that's my two cents worth - take it for what it's worth, it's late on a Friday. Good luck!

You might find it easiest to setup your pathing and current directory as the first commands in your script. For example, add the following to the script..


cd /home/wasadmin/jar
# Change current working directory to where the files are stored. While setting the PATH environment variable should cover this, if you reference any local files within subsequent scripts this adds some safety.

PATH=$PATH:/home/wasadmin/jar
# Setup the PATH to include the working directory. In this way, the line beginning with 'a.ct' should pick up the appropriate file.

As you can run the a.ct properly when running this logged in directly, it's not a case of permissions.

Absolutely true!

My reasoning was as follows:

1) awk can get confusing quickly and the OP is clearly new to Unix

2) Given that the OP is new to Unix, getting the idea across of piping output of one command to another seemed like a good step in their education.

You can use the following to cut out the top line automatically as well:

tail +2 stuff.txt | awk '{print $3}' > newfile.txt

Unix - a million ways to skin a cat!

FTP has it's own scripting capability - check that out first, I'd suggest.

#!/usr/bin/ksh

# use \c to suppress the default newline
echo "Enter userid: \c"
read USERID

# use \c to suppress the default newline
echo "Enter password: \c"

# set alt character set to obscure the password
tput smacs
read PASSWORD

# reset to standard character set
tput rmacs
echo ${USERID}:${PASSWORD} >> output.file


It's pretty basic but it'll do the job, if I understand your requirements correctly. You could always loop it until you select 'q' to quit or the like, depending on how sophisticated you want to make it.

Be careful with the following type of command:

ps aex | grep `echo $TOMCAT_PID` || echo "Tomcat process has stopped running"

Depending on the timing, you could well get a successful result even if the Tomcat process isn't running, as the grep command may well pick up itself in the ps listing! <command> | grep -v grep is often a lifesaver...

I've encountered that precise error recently. In our case, it occurred because we'd setup LDAP over SSL and in the process had to edit the 'wmm.xml' file. I realise you're not running your LDAP over SSL, but take a look at the PORTAL_ROOT/wmm/wmm.xml file - it actually recreates that file as part of the 'enable-ldap-security' configuration task, along with a few other files.

I suspect your problem is related to the Great Inode Confusion

cp abc.log abc.log.`date '+%Y-%m-%d'`
: > abc.log

Let's use some sample inode numbers - we'll say abc.log=inode 12345

In the first command, you're copying abc.log, which creates a copy successfully. abc.log.20060324=inode 23456

Your next command attempts to write to the existing abc.log IE it attempts to write to the beginning of abc.log which is inode 12345. Here's where the problem occurs - the program creating this log is still writing it's output to inode 12345 and still has that file open! I'd suggest checking your webserver/whatever program is generating the log and see what are the options for log rotation. Of course, you could always just restart the program nightly...

There are a few funky things you could try to get around this, but I'd suggest caution unless you're really certain what you're doing.

May I suggest that a likely problem is user authority to access the default Portal page/portlets? Try this:

Disable global security.

Ensure that the userid you're going to use to access Portal has authority to view/administer the portlets/Portal Applications you want available - note that this is the authorization within Portal itself, nothing to do with WAS!

Re-enable global security and test.

Good luck!