0

Hey there,

If you're doing this for C, you can just use quotes instead of the angle brackets, like

[CODE]#include "/home/yourdir/myInclude/header.sh"[/CODE]

If you're using a shell and your includes are functions, you can put them in your .profile, as advised above or just create your header.sh file and source it at the head of all of your script like:

[CODE]#!/bin/bash

. /home/yourdir/myIncludes/header.sh

code
code
code[/CODE]

and you'll be all set :)

, Mike

0

Hey Richard,

For both of those, you can capture the output of your test commands using backticks (will work in any shell) or the $() test in bash

For instance, you could take your statement:

[QUOTE]ps -ef | awk '/Cpu/ {if ($2 > 50 ) print "exceed"}'[/QUOTE]

and assign it to a variable

[QUOTE]xceeded=ps -ef | awk '/Cpu/ {if ($2 > 50 ) print "exceed"}'[/QUOTE]

or

[QUOTE]xceeded=$(ps -ef | awk '/Cpu/ {if ($2 > 50 ) print "exceed"}')[/QUOTE]

and then test that variable, for example:

[CODE]if [ $xceeded == "exceed" ]
then
do what have to do
fi[/CODE]

Let me know if that's enough of a nudge in the right direction. You're almost there :)

Best wishes,

Mike

0

Hey there,

Sometimes it will work if you just replace your exec call with a simple direct call, so instead of:

[QUOTE]exec $SHELL[/QUOTE]

just do

[QUOTE]$SHELL[/QUOTE] <-- Since you're not exec'ing (i.e. replacing the current process with your new process, you shouldn't get the session timeout error since you'll just be running your new bash on top of the old one. The downside is you have to exit the shell twice to logout.

And, since it works for your ssh, you can ssh in and check the status of the $- variable. Note what that is and then change your profile to simply run the new shell rather than exec it and check teh value of the variable as well. This will show you what options are automatically set when you login with bash via ssh versus direct login. If they're different, you can add a simple if-conditional in your profile to determine whether to exec your new shell or just run it straight-up and suffer with the double exit ;)

Just FYI, you can expect to see this kind of output when you query the $- built-in:

[QUOTE]echo $-
himBH[/QUOTE]

the output should be different for both connections.

Best wishes,

Mike

0

Hey There,

You're probably running into an issue with -p if you're just using a plaintext password. It expects the password to be encrypted using the crypt program (apologies if my assumption is incorrect.

One thing I was thinking was that it might be easier to create the script to add the 100 users, but have two lines (or comma separated single lines) with one doing the standard useradd and the other using "passwd" with the "--stdin" option, which you can automate with a pipe,

[QUOTE]useradd allYourOptionsExceptPassword user1
echo Myp@ssworD|passwd --stdin user1[/QUOTE]

Some food for thought anyway. Hope it helps!

Best wishes,

Mike

0

Hey there,

That can be done. Try this first though, since I find that "human readable" output is usually off. I would grab the information in kb and convert that to Mb. It will probably be more accurate than the output you generally get.

Which leads me to ask: Do you require specificity in your output to a great degree or are you looking for broad strokes (like 1.2Mb is fine even if it's technically 1.2475Mb)?

Thanks,

Mike

0

Hey There,

You coud use the output of format, although if you wanted to automate, you'd have to pipe the right commands to it and then do some processing on the other end, eg, for disk 0:

[QUOTE](echo 0;echo p;echo p)|format[/QUOTE]

The partition print shows size in MB - You really just need slice 2, since that represents the entire disk.

Also, I believe:

[QUOTE]iostat -En DIskname[/QUOTE]
or
[QUOTE]iostat -En[/QUOTE] <-- For everything and then parse it with sed/awk/what-have-you

may give you this info, but I don't have a SUn machine in front of me to verify.

Best wishes,

Mike

0

Hey there,

Just in case you have to do it the second way, this form works in bash 3.x (possibly earlier versions) and avoids the variable scoping problem while maintaining the integrity of the command you were feeding to the pipe.

[CODE]while read j1 j2 j3 j4 fsize j5 j6 j7 fname
do
[ ! -f $fname ] && continue

if grep $pattern "$fname" > /dev/null 2>%1
then
    total=`expr $total + $fsize`
    echo "size is: $total"
fi

done <<< "ls -l"
echo "Total size of files containing $pattern is: $total"[/CODE]

hope it helps :)

, Mike

0

Hey, ok, I see where you're coming from now :)

Actually, if you don't know where a particular process logs to, figuring that out from the process itself can be done, but it's not necessarily simple (although, hey, sometimes it is).

I would suggest that you do the log search prior to killing the PIDS associated with the process. Probably the best tools to use (although they may be a bit bulky) would be "lsof" or "truss" ("strace, xtrace, etc, all the same pretty much - depends on your distro of Linux or Unix).

In lsof you could do a simple

[QUOTE]lsof|grep PID[/QUOTE]

and then sift through that output to find any open files associated with the process (eyeball it first and then script the grep out)

for truss, strace, xtrace, etc try doing (I'll use truss for an example, but check the man page for whatever statement-tracing or execution tracing software your distro comes with:

[QUOTE]truss -f -p PID|egrep -i 'open|read|write|close'[/QUOTE]

and check out what files it opens and writes to and then script that out, after watching it manually.

Hopefully that helps. It might be difficult to get it, but it can be done. And, like I said, it might be really simple.

Oh, yes, one last thing - if you know the location of the program, you can run "strings" against it and probably find out where it logs to from that output:

[QUOTE]strings /full/path/to/dyyno[/QUOTE]

Best wishes,

Miek

0

That's an excellent suggestion, comatose. I also didn't realize what a huge pain this whole thing was for you, glamiss.

I think leaving the nice value at 0 (default) will make your program hog cpu less, but I wouldn't recommend rewriting shell script in tcl, since shell script is, essentially, just using the shell instead of having to add another layer of application on top.

As I mentioned, and agree with comatose, I would be looking at a solution that broke the problem. It might be easier to pick out when its not working properly (if it's a proper program, it may even complain) than to try and find it amidst a ps-sea of random proc's

Best of luck to you!

, Mike

0

Hey there,

If you're running syslog-ng, look into that. It has a history of doing exactly what you're experiencing.

Otherwise, since you know this action is recurring (something is chmod'ing your /dev/null) you could just run this in cron with one line and just "assume" the permissions have been changed.

[QUOTE]59 /bin/chmod 666 /dev/null >/dev/null 2>&1[/QUOTE]

and run a separate smaller shell script to just run

[QUOTE]ls -ld /dev/null
lsof|grep /dev/null
etc...[/QUOTE]

or whatever info you want to grab every 5 minutes or so for a day and then go over that and see if you can find some likely suspects. lsof should show you what processes/users are tapping /dev/null constantly.

Another crazy thing you could do - if you don't think it'll get you in trouble - would be to lock down /dev/null and, hopefully, make the process that's goofing with it go nuts ;)

If my suggestion sounds glib, I apologize. I'm just thinking you could figure this out using an alternate method and stick with the no-pain quick-fix until you do. Since the script doesn't attempt to find what program changed the perms, you don't need to make it so complicated.

Best wishes,

Mike

0

Hey There,

Two things, I think:

  1. You're not stripping the literal dollar sign from the figures you're trying to add

  2. Since you're invoking awk twice, you need to include your BEGIN def's twice

If you change the last line of your function to:

[CODE]sed 's/\$//' $dataFile|awk 'BEGIN{FS=","; RS="\n"} {total += $4}END{print total}'[/CODE]

it should work (although it's a simplistic sed equation that assumes only one $ per line), but you could save yourself some headach by just combining the two awk statements.

Best wishes,

Mike

0

Hey There,

It might have to do with the user agent string that wget passes to the site (I think it's something like wget-version). You can manipulate the --user-agent= variable to pass anything, just be careful that you don't use Mozilla as they're litigation happy (more details on the options page on wget's site regarding getting sued by them)

That's just one possibility.

Hope it helps :)

, Mike

0

Hey again,

Yes, I did and (thank you so much for the find output) I realized that I have been misunderstanding you this entire time. I wrote you back via PM so as not to take up too much space, with one final question regarding what you need to find with the find statement.

Needless to say, what you wanted makes complete sense now (that is, I was either misunderstanding at what level you wanted to create the zips and, probably, because I assumed the events subdirectories started with the literal "events" and not the names of events ;)

Thanks for the info. We're almost home :)

, Mike

0

Hey there,

Very basicly, it's an integer used to identy an open file in a process. In Unix/Linux/Posix 0, 1 and 2 are generally reserved for STDIN (standard input), STDOUT (standard output) and STDERR (standard error), in that order.

The integer (of file descriptor) are required as arguments to read, write and close operations. The integer, itself, is created by an open operation.

Best wishes,

Mike

0

Hey There,

Another way to go about it would be to do the math incrementally, within the loop, to avoid any possibility of losing the variables value when you exit the loop due to scope issues. You can do this by using $c as your counter variable, as well, so you don't run your function until all 3 answers have been received

For instance:

[CODE]for (( c=1; c<=3; c++))
do

read -p "Please insert Grade #$c:" GRD1
let GRD=$GRD+$GRD1
if [ $c -eq 3 ]
then
LetterGrade $GRD
echo
fi
done[/CODE]

Best wishes,

Mike

0

Hey There,

Okay - good :) As long as all you got back where directories and they were all named events1, events2, etc. If possible, can you PM me the output? If you're getting back any results you wouldn't expect and/or that output has spaces or single/double quotes, etc, that could be the issue.

I'd love to take a look at that output, since I can't replicate the issue on my computer.

Feel free to cut and paste and send me a PM. Since that's where you dead-end, I need to take a look at it to determine what step to take next.

If any of it's confidential, can you also just replace alphabetical characters with different alphabetical characters, etc. It's very important that the structure of the results remains intact. For instance a file name "hi there" would be an issue, but I'd never notice the space if it was sent as "****" :)

Best wishes,

Mike

0

Hey Again :)

Actually I was just asking if you could run either of those command from the command line (outside of the script) and see the output from those :)

[QUOTE]find /the/actual/path/to/your/dirs/ -type d -name "events[0-9]*"[/QUOTE]

all by itself should be good enough.

For example:

[QUOTE] # find /var/tmp/test
/var/tmp/test
/var/tmp/test/a
/var/tmp/test/a/a.file
/var/tmp/test/b
/var/tmp/test/b/b.file[/QUOTE]

If we can "not" run the rest of the script, we'll be able to see if the "find" command is returning any values or not. I'm assuming that it's not, but just want to be sure and can't try it on your machine :)

0

Hey,

Don't worry. You don't sound dumb. If you were dumb, you wouldn't ask questions ;)

Actually if you could do the find command with your full path and then the same with $EVENTDIR, that would be a good double-test, even though you "should" get the same results - you could do

[QUOTE]find $EVENTDIR -type d -name "events[0-9]*"[/QUOTE]

assuming $EVENTDIR has a value and

[QUOTE]find /the/actual/path/to/your/dirs/ -type d -name "events[0-9]*"[/QUOTE]

The output from either of those should probably lead us to the root of the problem.

Best wishes, it's almost fixed :)

, Mike

0

Hey there,

Well that's good news of a sort, since it's bringing us closer to an answer. Since that gives you same result from the CLI, I would take a look at this find statement:

[QUOTE]find /domains///*****.com/public_html/storage/events/ -type d -name 'events[0-9]*'[/QUOTE]

on its own. It's probably not returning anything. I would try it in order like:

[QUOTE]find /domains///*****.com/public_html/storage/events/[/QUOTE]

if this returns nothing, then the initial directory isn't correct

[QUOTE]find /domains///*****.com/public_html/storage/events/ -type d[/QUOTE]

if this returns nothing, then the initial directory doesn't have any directories in it (although it should because one of those directories would be itself)

[QUOTE]find /domains///*****.com/public_html/storage/events/ -type d -name "events[0-9]*"[/QUOTE]

if this returns nothing, then we know the problem is with the pattern matching glob (literal events followed by any number of digits - events1, events2, events54, etc)

Let me know how that goes and post the output if you can. Your Ubuntu should be all right. I'm on 8.04 Hardy now, but I don't recall ever noticing that the basic find command's functionality changed all that much (if at all) between distro's.

Take it easy :)

, Mike