Re: [PLUG] 2nd Router Setup
Neal wrote: > Sorry but I'm out of time for now. Good luck with it. > Me, too. Tomorrow's mostly tied up, but I'll try to fit in some more testing. Thanks for your help. -- Regards, Dick Steffens ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
On Sat, Apr 3, 2010 at 5:30 PM, Richard C. Steffens wrote: > Neal wrote: >> What does the WRT54G configuration page say the WAN IP address is? >> > > I set a static IP address of 192.168.0.250, a subnet mask of > 255.255.255.0, and a gateway of 192.168.0.1. > >> I would assume you're using DHCP for that. >> > > No. But when I tried changing to that I got an assigned IP from the > Netgear router of 192.168.0.5. I still can't ping the Netgear router > through the WRT54G. Do you observe the network connection for the WRT54G blinking on the Netgear router when you're trying to ping it? What should be happening is the 54G uses NAT to translate your laptop ping source IP to 192.168.0.5 (or .250, whichever is configured), forwards the ping to the Netgear, which replies back to the 54G, which un-NATs it back to your laptop IP address and forwards it out to the laptop. If the pings causes the Netgear LAN port to blink then it's getting that far but not coming back, or not all the way back as you can't visually distinguish whether the blinking means the ping packet arrived and was replied to or not. I think this should all Just Work with default settings on the 54G other than needing a network different from the Netgear LAN, including DHCP for WAN address. Did you reset it to factory defaults just for fun? ;-) Sorry but I'm out of time for now. Good luck with it. NealS ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
Neal wrote: > What does the WRT54G configuration page say the WAN IP address is? > I set a static IP address of 192.168.0.250, a subnet mask of 255.255.255.0, and a gateway of 192.168.0.1. > I would assume you're using DHCP for that. > No. But when I tried changing to that I got an assigned IP from the Netgear router of 192.168.0.5. I still can't ping the Netgear router through the WRT54G. -- Regards, Dick Steffens ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
On Sat, Apr 3, 2010 at 5:16 PM, Richard C. Steffens wrote: > Neal wrote: >> Can you ping the Netgear router? Cable modem? 208.67.216.231 (google)? >> > > No. The only thing the laptop can talk to is the WRT54G. What does the WRT54G configuration page say the WAN IP address is? I would assume you're using DHCP for that. NealS ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
Neal wrote: > Can you ping the Netgear router? Cable modem? 208.67.216.231 (google)? > No. The only thing the laptop can talk to is the WRT54G. -- Regards, Dick Steffens ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
> That worked, as far as finishing that part of the setup goes. But, the > laptop doesn't see the Internet. Wiring is as follows: > > Cable from street --> Cable Modem --> Netgear Router --> Switch --> > WRT54G Router --> Laptop Is the last link wired or wireless? > The laptop can log in to the WRT54G using Firefox, but doesn't see the > Internet -- trying to load the Google search page produces "Firefox > can't find the server at www.google.com." Can you ping the Netgear router? Cable modem? 208.67.216.231 (google)? If all of the above succeed the problem is with your DNS configuration. NealS ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
Neal wrote: > Actually, the WAN subnet and the LAN subnet are the same. So, I'm right. There is something fundamental I don't understand. > You must use > 192.168.1.x for the LAN if you're using 192.168.0.x for the WAN, or > vice-versa. > That worked, as far as finishing that part of the setup goes. But, the laptop doesn't see the Internet. Wiring is as follows: Cable from street --> Cable Modem --> Netgear Router --> Switch --> WRT54G Router --> Laptop The laptop can log in to the WRT54G using Firefox, but doesn't see the Internet -- trying to load the Google search page produces "Firefox can't find the server at www.google.com." BTW, to restate the ultimate goal, I'm trying to eliminate a cable running across the basement floor with the following wiring: Cable from street --> Cable Modem --> Netgear Router --> Switch --> WRT54G Router --> Linksys WET11 Wireless Ethernet Bridge --> ReplayTV DVR So, I haven't gotten to the wireless part, yet. -- Regards, Dick Steffens ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
On Sat, Apr 3, 2010 at 4:37 PM, Richard C. Steffens wrote: > The next section is Network Setup. I've assigned the WRT54G the IP > address of 192.168.0.251 and have set the Subnet Mask set to 255.255.255.0. > > When I try to save those settings I get an error message that says: > > The WAN IP address is same with the LAN IP address! Please check them again! > > Aren't 192.168.0.250 and 192.168.0.251 different? > > Am I missing something fundamental here? Actually, the WAN subnet and the LAN subnet are the same. You must use 192.168.1.x for the LAN if you're using 192.168.0.x for the WAN, or vice-versa. NealS ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] 2nd Router Setup
Time today permits working on this again. I'm endeavoring to set up a WRT54G ver. 6 as a wireless access point. Using my laptop, I have connected its wired Ethernet port to one of the 4 ports on the back of the WRT54G and logged in to the WRT54G's administration page. On the Setup tab. The first section is for Internet Setup. Here, I have chosen to use a Static IP of 192.168.0.250, Subnet Mask: 255.255.255.0, and a gateway of 192.168.0.1, which is the LAN IP address if my Netgear router. In the Optional Settings section I have given the WRT54G a Router Name of BsmtRtr. The next section is Network Setup. I've assigned the WRT54G the IP address of 192.168.0.251 and have set the Subnet Mask set to 255.255.255.0. When I try to save those settings I get an error message that says: The WAN IP address is same with the LAN IP address! Please check them again! Aren't 192.168.0.250 and 192.168.0.251 different? Am I missing something fundamental here? -- Regards, Dick Steffens ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] bash question
Denis Heidtmann wrote: > On Sat, Apr 3, 2010 at 11:34 AM, Fred James wrote: > > >> Denis Heidtmann wrote: >> >>> [many omissions for bevity] >>> >>> Your explanation does indeed help me understand what gdmwhich() does. >>> Since my script resides in one of my directories not in the $PATH, I >>> >> chose >> >>> to execute it above the setting of IFS to : using its fully qualified >>> >> path. >> >>> It executes fine, and does what is intended. However, if I source my >>> script rather than execute it, the argument does not get passed. I am >>> assuming now that this behavior is normal for dash. My remedies are 1) >>> >> to >> >>> execute my script in PostSession/default, in which case the argument is >>> passed as expected, or 2) source a special script which has the argument >>> hard-coded in it. >>> >>> To decide which remedy to choose I would like to know why the Debian >>> >> Policy >> >>> states that scripts used should be sourced. If violating that policy >>> >> would >> >>> cause no problem that would be my choice. That is what I have set up at >>> present, and I have noticed no problems. However, lacking the >>> >> understanding >> >>> of the motivation for the Policy, I cannot be certain that a problem will >>> not arise. >>> >>> So, in summary, my original question was: Why does the argument not get >>> passed with a sourced invocation? (answer: normal behavior of dash). The >>> question now is: If I execute a script from PostSession/default will I >>> >> cause >> >>> a problem? >>> >>> Thanks so much for the effort you have put in toward my education. >>> >>> -Denis >>> >>> >> Denis Heidtmann >> While the most straight forward way could be to simply hard code the >> full_path_name_to_your_executable into the appropriate Default >> executable, that would create a maintenance problem with Default, and >> could cause unexpected behavior should your_executable not be found >> there, or fail for some reason (i.e., one would have to add all of the >> appropriate exception handling routines to Default, and then do it all >> over again, including the appropriate testing, every time there was an >> upgrade. >> >> But to add a line or two to Default to (a) get the full path name, and >> then (b) execute your_executable, changes the complexion ... for one >> thing, gdmwhich has a bit of error handling in that it returns nothing >> (empty string) if it cannot find your_executable, and nothing on a line >> by itself (within a program, in this case Default) doesn't do anything, >> so there isn't a problem. OK? >> >> Now, suppose we thought ... oh, but there may be some unknown number of >> new executables that might be called within Default (at some time in the >> future?) Well then we might want to make a text file to contain the >> list of those new executables, and add a routine to Default to browse >> through that list, finding the executables, complete their paths, and >> call them each sequentially. >> >> That much said, perhaps we should turn our attention to "if I source my >> script rather than execute it, the argument does not get passed." Could >> you please, state what is happening here? For example: From withing >> Default you are calling script_1, is that correct? >> >> If that is correct, are you attempting to pass an argument to script_1? >> >> And then, what does script_1 do? For example: Does it try to return >> some value to Default? >> >> Any clarification would be most welcome >> Regards >> Fred James >> >> > > I realize the simple approach of hard-coding the full path to my script > presents a maintenance problem, but perhaps I am willing to live with that. > > My script simply writes the date and time followed by a word of text to a > log file. The word of text is the argument passed to my script, or if no > argument, the word of text is "UNKNOWN". If my script is invoked from > Default by being sourced, no argument is received by my script, so the entry > in my log is labeled "UNKNOWN". I have currently solved this problem by > detecting that the script was sourced, assume it was invoked from Default, > and set the word of text to "Logout". I can refine this by checking that > Default was the caller; I have not done that yet. > > If something goes wrong, for whatever reason, I may lose some data, but that > is a risk I am willing to take. Only if calling my script throws an error > within Default such that Default fails to do its intended job am I > concerned. Since Default does nothing at present, I feel pretty safe. > > -Denis > Denis Heidtmann Thank you for your reply. I confess I have not found anything that would suggest that the program called must/should be sourced, and I am at a loss on that score - sorry. Your solution is as good as any I may suggest - the real reason for possibly following one of the other paths mentioned appears when
Re: [PLUG] bash question
On Sat, Apr 3, 2010 at 11:34 AM, Fred James wrote: > Denis Heidtmann wrote: > > [many omissions for bevity] > > > Your explanation does indeed help me understand what gdmwhich() does. > > Since my script resides in one of my directories not in the $PATH, I > chose > > to execute it above the setting of IFS to : using its fully qualified > path. > > It executes fine, and does what is intended. However, if I source my > > script rather than execute it, the argument does not get passed. I am > > assuming now that this behavior is normal for dash. My remedies are 1) > to > > execute my script in PostSession/default, in which case the argument is > > passed as expected, or 2) source a special script which has the argument > > hard-coded in it. > > > > To decide which remedy to choose I would like to know why the Debian > Policy > > states that scripts used should be sourced. If violating that policy > would > > cause no problem that would be my choice. That is what I have set up at > > present, and I have noticed no problems. However, lacking the > understanding > > of the motivation for the Policy, I cannot be certain that a problem will > > not arise. > > > > So, in summary, my original question was: Why does the argument not get > > passed with a sourced invocation? (answer: normal behavior of dash). The > > question now is: If I execute a script from PostSession/default will I > cause > > a problem? > > > > Thanks so much for the effort you have put in toward my education. > > > > -Denis > > > Denis Heidtmann > While the most straight forward way could be to simply hard code the > full_path_name_to_your_executable into the appropriate Default > executable, that would create a maintenance problem with Default, and > could cause unexpected behavior should your_executable not be found > there, or fail for some reason (i.e., one would have to add all of the > appropriate exception handling routines to Default, and then do it all > over again, including the appropriate testing, every time there was an > upgrade. > > But to add a line or two to Default to (a) get the full path name, and > then (b) execute your_executable, changes the complexion ... for one > thing, gdmwhich has a bit of error handling in that it returns nothing > (empty string) if it cannot find your_executable, and nothing on a line > by itself (within a program, in this case Default) doesn't do anything, > so there isn't a problem. OK? > > Now, suppose we thought ... oh, but there may be some unknown number of > new executables that might be called within Default (at some time in the > future?) Well then we might want to make a text file to contain the > list of those new executables, and add a routine to Default to browse > through that list, finding the executables, complete their paths, and > call them each sequentially. > > That much said, perhaps we should turn our attention to "if I source my > script rather than execute it, the argument does not get passed." Could > you please, state what is happening here? For example: From withing > Default you are calling script_1, is that correct? > > If that is correct, are you attempting to pass an argument to script_1? > > And then, what does script_1 do? For example: Does it try to return > some value to Default? > > Any clarification would be most welcome > Regards > Fred James > I realize the simple approach of hard-coding the full path to my script presents a maintenance problem, but perhaps I am willing to live with that. My script simply writes the date and time followed by a word of text to a log file. The word of text is the argument passed to my script, or if no argument, the word of text is "UNKNOWN". If my script is invoked from Default by being sourced, no argument is received by my script, so the entry in my log is labeled "UNKNOWN". I have currently solved this problem by detecting that the script was sourced, assume it was invoked from Default, and set the word of text to "Logout". I can refine this by checking that Default was the caller; I have not done that yet. If something goes wrong, for whatever reason, I may lose some data, but that is a risk I am willing to take. Only if calling my script throws an error within Default such that Default fails to do its intended job am I concerned. Since Default does nothing at present, I feel pretty safe. -Denis ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] bash question
Denis Heidtmann wrote: > [many omissions for bevity] > Your explanation does indeed help me understand what gdmwhich() does. > Since my script resides in one of my directories not in the $PATH, I chose > to execute it above the setting of IFS to : using its fully qualified path. > It executes fine, and does what is intended. However, if I source my > script rather than execute it, the argument does not get passed. I am > assuming now that this behavior is normal for dash. My remedies are 1) to > execute my script in PostSession/default, in which case the argument is > passed as expected, or 2) source a special script which has the argument > hard-coded in it. > > To decide which remedy to choose I would like to know why the Debian Policy > states that scripts used should be sourced. If violating that policy would > cause no problem that would be my choice. That is what I have set up at > present, and I have noticed no problems. However, lacking the understanding > of the motivation for the Policy, I cannot be certain that a problem will > not arise. > > So, in summary, my original question was: Why does the argument not get > passed with a sourced invocation? (answer: normal behavior of dash). The > question now is: If I execute a script from PostSession/default will I cause > a problem? > > Thanks so much for the effort you have put in toward my education. > > -Denis > Denis Heidtmann While the most straight forward way could be to simply hard code the full_path_name_to_your_executable into the appropriate Default executable, that would create a maintenance problem with Default, and could cause unexpected behavior should your_executable not be found there, or fail for some reason (i.e., one would have to add all of the appropriate exception handling routines to Default, and then do it all over again, including the appropriate testing, every time there was an upgrade. But to add a line or two to Default to (a) get the full path name, and then (b) execute your_executable, changes the complexion ... for one thing, gdmwhich has a bit of error handling in that it returns nothing (empty string) if it cannot find your_executable, and nothing on a line by itself (within a program, in this case Default) doesn't do anything, so there isn't a problem. OK? Now, suppose we thought ... oh, but there may be some unknown number of new executables that might be called within Default (at some time in the future?) Well then we might want to make a text file to contain the list of those new executables, and add a routine to Default to browse through that list, finding the executables, complete their paths, and call them each sequentially. That much said, perhaps we should turn our attention to "if I source my script rather than execute it, the argument does not get passed." Could you please, state what is happening here? For example: From withing Default you are calling script_1, is that correct? If that is correct, are you attempting to pass an argument to script_1? And then, what does script_1 do? For example: Does it try to return some value to Default? Any clarification would be most welcome Regards Fred James ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] short version [Was: Re: bash question]
Denis Heidtmann
The short version is ...
(1) put a non-interactive executable in a directory somewhere in the
defined PATH - set permission correctly of course
(2) in the appropriate Default script, somewhere between the gdmwhich
function and exit (probably closer to exit?), get the full path to that
executable mentioned in step 1 ... something like this ...
command_to_execute=`gdmwhich name_of_program_without_path`
(3) execute that program, such as ...
command_to_execute
(3.1) of course the call for "command_to_execute" should be within some
sort of control structure for any appropriate exception handling, eh?
Does that help?
Regards
Fred James
[omissions for brevity]
Denis Heidtmann (sorry ... I have been misspelling your name ... sorry)
[more omissions for brevity]
gdmwhich () {} ...
Pre gdmwhich () the value of IFS is saved and then set to :
Then the directories in $PATH are searched for a match to COMMAND (which
is set to $1)
If the COMMAND is found and it is executable (test -x) and if the OUTPUT
is an empty variable (since OUTPUT= the "x$OUTPUT" should be "x")
set OUTPUT to be the directory in which COMMAND was found, followed
by COMMAND (inserting the required /, of course)
Reset IFS to its old value
"echo" or return that value of $OUTPUT
So far so good?
Now ... in both my PreSession and PostSession, the PATH is set to
include $PATH, /bin, and /usr/bin, although in PostSession /usr/bin is
listed twice (see above in quoted message)
In my PreSession there is the line ...
XSETROOT=`gdmwhich xsetroot`
... note that those are the forward single quotes (normally found on the
'~' key?), which calls the function with the argument xsetroot, setting
XSETROOT to whatever is returned (echo'd)
in other words the value of XSETROOT is whatever directory gdmwhich
() finds xsetroot in, followed by /, followed by xsetroot - in my case
that would be /usr/bin/xsetroot - your mileage may vary.
That does assume that xsetroot is found, of course, otherwise OUTPUT is
empty.
Does any of that help, or did I miss something?
Regards
Fred James
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] bash question
On Sat, Apr 3, 2010 at 8:18 AM, David Fleck wrote: > On Fri, 2 Apr 2010, Denis Heidtmann wrote: > > Is there a way for my script to detect that it is sourced rather than > > executed? > > I can think of a few tests, but since none of my machines have dash, I > can't guarantee they will work > > You can write the name of the script into a variable, and compare that > with the value of '$0'. If they match, then the script was executed; if > not, it was sourced: > > #!/bin/sh > . $HOME/script1.sh full > . ./script1.sh relative > > sh $HOME/script1.sh exec > > > #! /bin/sh > self=script1.sh > called=`basename $0` > > if [ "$self" != "$called" ]; then > echo "I am sourced: $@" > else > echo "I am executed: $@" > fi > > > ]$ sh script2.sh > I am sourced: full > I am sourced: relative > I am executed: exec > > > Your problem sounds like a bug in dash. > > -- > David Fleck > david.fl...@mchsi.com Neat! I will give it a try. If it works in dash, it will solve my problem quite neatly. I do not know if my problem is a dash bug or a feature. -Denis ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] bash question
On Fri, Apr 2, 2010 at 7:31 PM, Fred James wrote:
> Denis Heidtmann wrote:
> > On Fri, Apr 2, 2010 at 2:01 PM, Fred James >wrote:
> >
> >
> >> Denis Heidtmann wrote:
> >>
> >>> On Fri, Apr 2, 2010 at 12:39 PM, Denis Heidtmann
> >>> wrote:
> >>>
> >>>
> >>>
> On Fri, Apr 2, 2010 at 11:55 AM, Joe Pruett wrote:
>
>
>
> > bash 3.2 on my system doesn't show this problem. are you sure the
> full
> > path and relative path actually get to the same script? could you be
> > accidentally running two different scripts? or maybe it is some odd
> > bash bug, what version do you have?
> >
> >
> >
> Since /etc/gdm/PostSession/Default is a .sh script, I must use that
>
> >> shell,
> >>
> also known as dash. Maybe bash will not show the problem. I have
>
> >> version
> >>
> 3.2.48(1)-release (x86_64-pc-linux-gnu).
>
> -Denis
>
> It turns out that I jumped to an invalid conclusion. The issue is
> not
>
>
> >>> with bash, but with dash. But my problem remains. I need to use
> dash,
> >>>
> >> and
> >>
> >>> the policy wants the script to be sourced. My only solution at this
> time
> >>>
> >> is
> >>
> >>> to have a separate script with the argument coded into it. I would
> >>>
> >> prefer
> >>
> >>> not to do that, but even more I would like to understand the behavior.
> >>>
> >>> -Denis
> >>>
> >>>
> >> Dennis Heidtmann
> >> Well, first let's see if we are on the same page ... OK?
> >>I run Mandriva 2008 and ...
> >>(1) /bin/sh -> bash
> >>(2) instead of /etc/gdm/PostSession/Default I have
> >> /etc/X11/gdm/PostSession/Default
> >>(2.1) I have included the text of /etc/X11/gdm/PostSession/Default
> >> below for comparison
> >>(3) if we are anywhere near on the same page ... could you show me
> >> what you are trying to do?
> >> ... hoping to help
> >> Regards
> >> Fred James
> >>
> >> [text of /etc/X11/gdm/PostSession/Default from Mandriva 2008]
> >> #!/bin/sh
> >>
> >> PATH="/usr/bin:$PATH:/bin:/usr/bin"
> >> OLD_IFS=$IFS
> >>
> >> gdmwhich () {
> >> COMMAND="$1"
> >> OUTPUT=
> >> IFS=:
> >> for dir in $PATH
> >> do
> >>if test -x "$dir/$COMMAND" ; then
> >> if test "x$OUTPUT" = "x" ; then
> >>OUTPUT="$dir/$COMMAND"
> >> fi
> >>fi
> >> done
> >> IFS=$OLD_IFS
> >> echo "$OUTPUT"
> >> }
> >>
> >> exit 0
> >>
> >> I want to log the time of logoff. I was directed to
> >>
> > gdm/PostSession/default by:
> >
> >
> http://people.uleth.ca/~daniel.odonnell/Blog/lost-in-logout-land-running-scripts-on-login-and-logout-partially-solved-but-interesting-anyway
> >
> > Method 1: /etc/gdm/PostLogin/Default, /etc/gdm/PreSession/Default, and
> > /etc/gdm/PostSession/Default
> >
> > "If you have a shell script that does not require user intervention, you
> can
> > run it automatically immediately after Login, immediately before the
> start
> > of the Gnome Session (i.e. before the desktop is drawn), and immediately
> > after your Gnome Session (i.e. after the Desktop closes down), by
> launching
> > it from /etc/gdm/PostLogin/Default, /etc/gdm/PreSession/Default, and
> > /etc/gdm/PostSession/Default respectively. "
> >
> > I do not understand the function gdmwhich. I just added a line executing
> my
> > script, using the fully qualified path. The argument of the script,
> Logoff,
> > is placed in my log file, since other events get put in that file as
> well.
> > If I source my script rather than executing it, the argument does not
> get
> > received by my script.
> >
> > I am running ubuntu 9.04
> >
> > This is not a huge problem. I can create a duplicate of my script which
> has
> > Logoff hard-coded into it. But I would like to understand why dash does
> not
> > pass the argument when the script is sourced.
> >
> > Is there a way for my script to detect that it is sourced rather than
> > executed?
> >
> > -Denis
> >
> Denis Heidtmann (sorry ... I have been misspelling your name ... sorry)
> To be clear ...
> First, my system
>does not have any files in the /PostLogin directory
>does have a Default script in each of the PreSession and PostSession
> directories, but no other files are found there
> Second, I am not sure the Default files you have are exactly like the
> ones I have
>
> However ... assuming they are similar at least ...
>
> gdmwhich () {} ...
> Pre gdmwhich () the value of IFS is saved and then set to :
> Then the directories in $PATH are searched for a match to COMMAND (which
> is set to $1)
> If the COMMAND is found and it is executable (test -x) and if the OUTPUT
> is an empty variable (since OUTPUT= the "x$OUTPUT" should be "x")
>set OUTPUT to be the directory in which COMMAND was found, followed
> by COMMAND (inserting the required /, of course)
> Reset IFS to its old value
> "echo" or return that value of $OUTPUT
>
> So far so good?
>
> Now ... in both my PreSession and PostSession, the PATH is set to
> include $PATH, /bin, and /u
Re: [PLUG] bash question
On Fri, 2 Apr 2010, Denis Heidtmann wrote: > Is there a way for my script to detect that it is sourced rather than > executed? I can think of a few tests, but since none of my machines have dash, I can't guarantee they will work You can write the name of the script into a variable, and compare that with the value of '$0'. If they match, then the script was executed; if not, it was sourced: #!/bin/sh . $HOME/script1.sh full . ./script1.sh relative sh $HOME/script1.sh exec #! /bin/sh self=script1.sh called=`basename $0` if [ "$self" != "$called" ]; then echo "I am sourced: $@" else echo "I am executed: $@" fi ]$ sh script2.sh I am sourced: full I am sourced: relative I am executed: exec Your problem sounds like a bug in dash. -- David Fleck david.fl...@mchsi.com ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
