Saw this line in pt3inst.log:

protop.pf already exists in etc, saving a copy as /opt/protop/etc/protop.pf.04.19

The new protop.pf does contain -inp 16384. So it looks like all is well with pt3upd.sh.

They just aren't on the install screen anymore.

Oh, okay. I assumed I made that feature go away somehow...

As much as I would love to figure it out I suspect that blowing it away and starting over is probably the smart thing to do.

FWIW -- LOGDIR & TMPDIR are still supposed to be user configurable. They just aren't on the install screen anymore. My UX advisors advised me that it was too much decision making to expect from users

Are there any potential permissions problems?

Not that I'm aware of.

This installation dates back to when directories like "TMPDIR" were user-configurable; mine is "temp".I checked pt3upd.sh and it seems to use $TMPDIR everywhere it should, and not assume the temp dir is "$PROTOP/tmp".

I also tried renaming temp to tmp and updating protopenv accordingly but "bin/pt3upd.sh" still fails. The file pt3inst.err is not created. This is the entirety of update.log, from the latest run:

Tue Apr 17 15:56:38 EDT 2018 begin bin/pt3upd.sh
-src.tar
Tue Apr 17 15:56:38 EDT 2018 curl -o /opt/protop/tmp/-src.tar.gz http://dbappraise.com/pt3upd/-src.tar.gz
Tue Apr 17 15:56:39 EDT 2018 restarting monitors
Tue Apr 17 15:56:39 EDT 2018 end bin/pt3upd.sh

I may just blow it away and install from scratch.

lib/install.p is called at the end of pt3upd.sh, the installer is supposed to tailor the contents of estub and mostly replace things in etc or bin along the way.

There should be log/update.log and tmp/pt3inst.err files being created along the way too.

Can you manually download successfully?

Yes, that works.

Why did you put a "./" in front of pt3upd.sh? Have you also done a cd to $PROTOP/bin or something like that?

That was actually my second attempt, and yes it was done in $PROTOP/bin. My first was "bin/pt3upd.sh" in $PROTOP, and it threw the same kind of error.

I tried again with "pt3upd.sh pt3.3s" and it ran to completion but it didn't replace my copy of etc/protop.pf.

Why did you put a "./" in front of pt3upd.sh? Have you also done a cd to $PROTOP/bin or something like that? That seems odd. It shouldn't matter - the pt3upd.sh script does a cd ${PROTOP} to get around that sort of thing.

When I run it I get output like this:

proenv> pt3upd.sh
Tue Apr 17 14:57:13 EDT 2018 Updating to latest release
Tue Apr 17 14:57:13 EDT 2018 pt-src.tar
Tue Apr 17 14:57:13 EDT 2018 curl -L -o /home/protop/tmp/pt-src.tar.gz http://demo.wss.com/pt3upd/pt-src.tar.gz
...

The lack of an "Updating to..." line and a message showing what curl command will be run in your output is puzzling.

You clearly didn't get a valid download - that's why gzip is complaining.

Can you manually download successfully?

proenv> curl -L -o /home/protop/tmp/pt-src.tar.gz http://demo.wss.com/pt3upd/pt-src.tar.gz

$ ./pt3upd.sh
-src.tar
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
145   291  145   291    0     0   1705      0 --:--:-- --:--:-- --:--:--  8083

gzip: /opt/protop/temp/-src.tar.gz: not in gzip format
tar: /opt/protop/temp/-src.tar: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
Tue Apr 17 14:50:57 EDT 2018 restarting monitors
Tue Apr 17 14:50:57 EDT 2018 end ./pt3upd.sh

proenv>  pt3upd.sh

Will fetch and install the fixed package. Just in case. (Add ".sh" if you are downloading on UNIX...)

Now I am extra grouchy.

You were supposed to get a new protop.pf with "-inp 16384".

Grumble, grumble...