Re: Re: Raspberry PI synchron
  By: KK4QBN to Digital Man on Sun Feb 18 2018 09:48 am

 >   Re: Re: Raspberry PI synchron
 >   By: Digital Man to KK4QBN on Sat Feb 17 2018 19:31:33
 >
 >  >> kk4qbn@kk4qbn:~$ cat hi.sh
 >  >> export HELLO=Hi!
 >
 >  >> kk4qbn@kk4qbn:~$ md5sum hi.sh
 >  >> 7771bfae728b34ec658674c6cbe2281f  hi.sh
 >  >> kk4qbn@kk4qbn:~$ source hi.sh
 >  >> kk4qbn@kk4qbn:~$
 >
 >  >> See.. somethink is BORKED!
 >
 >  DM> Yes. You need to slow down and actually look at what you're typing and
 >  DM> copying and pasting.
 >
 > The last message I typed I accidently aborted, anyway.. I see where I scrwed
 > that up and did'nt have echo $HELLO in the hi.sh I think this occured from
 > the typo in the last message I'd have to look to be sure but it don't really
 > matter.. the md5sum is indeed the same now..
 >
 > kk4qbn@kk4qbn:~$ cat hi.sh
 > export HELLO=Hi!
 > echo $HELLO
 > kk4qbn@kk4qbn:~$ md5sum hi.sh
 > f7201385bdb7c523dade158d270014cc  hi.sh

And when you "source hi.sh", does it print "Hi!"?

 >  DM> Like I said before, let's back up and not use 'sbbs' to test your
 >  DM> ability to set environment variables.
 >
 > I am not.. I'm using it as an example along with the fact that I have to
 > force the /sbbs/ctrl directory upon SCFG to get it to work correctly and
 > have to do the same with jsexec.

Please be more specific.

If you execute  'echo $SBBSCTRL' and it echoes back '/path/to/ctrl' (whatever
that is) and then from the same command prompt, you execute jsexec (not a
script), you're telling me it reports an error about the SBBSCTRL environment
variable?

 >  DM> Well most of those files are only used by bash. Are you using bash? If
 >  DM> you're at a shell prompt, and you run 'ps', does the output look like
 >  DM> this?
 >
 > Yes, I am using bash
 >
 >   PID TTY          TIME CMD
 > 10933 pts/3    00:00:00 bash
 > 11328 pts/3    00:00:00 ps
 >
 >
 >  >> well 'env' states that SBBSCTRL is indeed set
 >
 >  DM> When does it state that? After a fresh boot and opening a new terminal
 >  DM> window? If so, then one of those files that bash (or whatever shell
 >  DM> you're using) is parsing, is working. Did you maybe set different
 >  DM> values in each to find out which is/are working?
 >
 > after a fresh boot, and there are no different values nowhere.

I don't think you understood my suggestion. My suggestion was to set different
environment variables (called them ENVTEST1, ENVTEST2, etc. or whatever) in
each method you know of to set an environment variable. e.g. in your
/etc/profile, add:

export ENVTEST1='/etc/profile worked!'

Set a different variable to a different value in the other files. Then:
- reboot
- open a terminal window (you are running an X desktop, yes?)
- type 'env' and report back which methods worked and which did not

 >  >> /etc/environment is not doing what I thought it would. its scrweing
 >  >> with the programs. try to run scfg and you get !ERROR 2 changing
 >  >> curent directory to /sbbs/ctrl.. guess I'll trash that and reboot and
 >  >> keep trying.
 >
 >  DM> Is the ".." part of the error messge? that would indicate a typo
 >  DM> somewhere.
 >
 >  > DM>> And if the SBBSCTRL environment variable shows up in 'env' output
 >  > DM>> (or its value can be echoed via $SBBSCTRL) and sbbs still reports
 >  > DM>> that error, then revisit your methods of starting sbbs - if it's a
 >  > DM>> shell script, revisit the contents of that that shell script.
 >
 > No the .. was me I was typing the error from a different terminal..

I suggest you copy and paste the exact error message. "Error 2 changing current
directory" indicates that the directory does not exist. Does the '/sbbs/ctrl'
directory exist?

 > I'll
 > keep checking everything.. but it's not just sbbs giving errors so I don't
 > think the script is the issue, I will go back over everything again when I
 > get time. for the time though everything is running smooth the way it is..
 > It just bugs me that this is happening.
 >
 >  DM> Welp, we need to slow down backup and find out if you're able to set
 >  DM> environment variables and where. If you're setting them in a shell
 >  DM> script, I already explained that they don't live up beyond the script
 >  DM> (unless you "source" it). But you kind of seem to be all over the map
 >  DM> on what you're trying and what you're reporting is working or not
 >  DM> working. Simplify. Pick one test and start there until you understand
 >  DM> why it's not working and how to make it work.
 >
 > I will set the varaiables in one file at a time and try it. but as I said,
 > it shows to be already set, I might make a typo from time to time, but one
 > cannot get much slower than I am.. I'm fairly methodical of the methods I
 > use. the ONLY reason I set them in scripts is because sbbs, scfg, and jsexec
 > were giving issues.. otherwise I would'nt be "all over the map" usually
 > setting an envorinment variable should be fairly straight forward.. right?

Well it can be tricky given that processes (including scripts invoked as
executeables) get a *copy* of their parent script and any changes made are that
copy, which disappears when the process/script is finished. This is a bit
different from Windows, where batch/cmd files can set environment variables in
their parent environment without issue.

                                            digital man

This Is Spinal Tap quote #37:
David St. Hubbins: We are Spinal Tap from the UK - you must be the USA!
Norco, CA WX: 66.4øF, 41.0% humidity, 5 mph NE wind, 0.00 inches rain/24hrs
--- SBBSecho 3.03-Win32