ksh shell (run via bash) - script/path execution question

Edit: Title of thread updated to address comments that ‘title’ misleading

= = = = = =
I am puzzled on both a LEAP-15.2 and LEAP-15.3 system, and I am lacking in understanding quite possible some basic bash/ksh functionality.

I am attempting to run a ‘setup’ script (which I obtained from here ( http://technology.research-lab.ca/2021/01/upscale-and-interpolate-video-super-resolution-using-starnet/ ) .

The instruction line (which don’t work for me (which I highlighted below in bold) are:


To download and install the project:
>wget -O - https://github.com/arnon-weinberg/Upscale-interpolate-STARnet/archive/master.tar.gz | tar xz
>cd Upscale-interpolate-STARnet-master
**>setup**
>source pytorch/bin/activate
>upscale --help

Note ‘setup’ is a script.

The script is intended to be run in the user space / environment (not run as root). However when ever I run it, even if I am in the " /home/oldcpu/Upscale-interpolate-STARnet-master " directory I constantly go down the script path " Please run this script from its directory " … which to me begs the question, how do I run the script from its directory (given the bash shell is already navigated to the noted directory) ?

Note the first section of the “setup” script has:


if  $0 != "setup" ]]
then
  echo "Please run this script from its directory."
  exit
fi

I note “echo $0” always gives /bin/bash and if I run ‘ksh’ first, then “echo $0” always gives “ksh”. I do not see how to make $0 equal to ‘setup’.

Likely (?) I am missing something obvious - and I would be interested to learn how to fix my mistake.

I experimented using bash (I normally use “csh”). And with bash, “$0” appears to be the path, not just the command name.

With “csh”, I get $0=setup provided that “.” is on the PATH (which it normally isn’t for me).

It is a poorly designed script. They should tell you to use
./setup
as the command, and they should test for $0="./setup" (in my opinion).

Don’t worry. Bypass the annoyance. Use “bash setup”.

This requires current directory to be in PATH which is not default, so it should not even execute this command.

when ever I run it, even if I am in the " /home/oldcpu/Upscale-interpolate-STARnet-master " directory I constantly go down the script path " Please run this script from its directory " … which to me begs the question, how do I run the script from its directory (given the bash shell is already navigated to the noted directory) ?

We have no idea how you run it. Instead of describing what you did you should have provided copy and paste (or screen output capture) of exact commands and their output that you used. As I already mentioned, this should simply have failed to find script “setup” or it has found some entirely different command.

if $0 != “setup” ]]

I wonder what shell and operating system was used to actually test this script. For all I can tell this can never work.

I note “echo $0” always gives /bin/bash

No, it does not. bash manual provides pretty detailed and clear explanation how value of $0 is set. Did you try to read it before posting?

and if I run ‘ksh’ first

Why you suddenly mention ksh? What it has to do with it?

I do not see how to make $0 equal to ‘setup’.

$ bash -c 'echo $0' setup
setup

But it probably does not help your script. $0 expands to pathname of script and will always include at least ./ prefix when PATH contains current directory. So this condition cannot match. Again, unless this was intended for some special version of shell.

Edit: this condition works when started from within interactive ksh, because ksh does not prepend ./ to executable found in empty PATH element. The remark about PATH still holds - this is not default.

**erlangen:~ #** cat setup  
echo $0 
**erlangen:~ #** bash setup  
setup 
**erlangen:~ #**

I did try adding the current directory to the path. It made no difference.

I navigated to the directory and ran " ./setup" … I did not realize sending “bash setup” was another way to run it (ie with different path characteristics).

Yes, … its complex, takes a lot of time, and my efforts to dig through it did not help.

the script was created in ksh - and I mentioned that in case someone else tried the same as me. The first line of the script was: " #!/bin/ksh" but given the # and that it was commented out, and given the entire script long, and not relevant to the issue, I did not include the entire script.

It turns out in bash, navigating to the directory with the script, and then typing “bash setup” actually works (thus far, this script is still running 10 minutes later). It never occurred tome that "bash setup’ would be different from “./setup”.

Interesting. Thanks.

Typing “bash setup” (instead of the “./setup” which I tried initially) does get past that “$0” check.

Script is still running as I type this.

If script was created for ksh, you are lucky it performs correctly under bash. In this case another way to run it is “ksh setup”, not “bash setup”.

I have tried both “ksh setup” and “bash setup”.

Both fail with identical errors further in the script.

I’m am investigating.

Apart from the problem itself, it is of course not a good idea to do if #!/bin/ksh is unimportant. It is crucial to get the correct interpreter for the script and it was of course put there by the programmer of the script to be like that.

This, so called “shebang”, should not be removed. yes, it is a comment line during the execution of the script by /bin/ksh, but before that it tells the kernel to execute /bin/ksh and not any other interpreter like python or bash or csh, to interpret the script. And thus even the mentioning of bash as having anything to do with this script is like introducing Fortran as having something to do with a C program problem.

In other words, you have put all readers of this thread on the wrong leg by doing as if it has something to do with bash and the title of the thread is completely off topic.

My impression is that the script is lousy. When the programmer thinks it is needed that the working ditectory should be the same directory where the script is, one of the first lines could have been (works in ksh)

cd $(dirname ${0})

While the input is appreciated, honestly that was not so helpful.

I tried to put caveats in my first post associated with my help request …

To quote:

Clearly those caveats were not good enough for you ( I did note ‘ksh’ where obviously the complete significance of that line, which was commented out in the script ( #/bin/ksh ) ) , at the script start , was clearly lost on me. Only after " arvidjaar’s" 1st post in this thread did I sense ‘bash’ and ‘ksh’ could be part of the issue …

Still I do note that further in my 1st post in that thread, where I tried to make it clear I could be missing something obvious.

That is part of the very reason I was asking for help.

My view in help threads is if one expects titles to be 100% accurate when help requests are given - well - we live in totally different help providing worlds. I would like to more know about GNU/Linux than I do, and yes there are areas where my knowledge is very weak.

Anyway - much appreciated to EVERYONE in this thread for the quick feedback. It is been educational and apologies for those who demanded a better title when I struggled with the issue … learning is 1/2 the purpose of all this for me.

I updated the thread title to address the comments of those who noted Title misleading.

For the record, my help request specific to this thread has been answered - so the question can be considered solved.

= = =

I am still struggling to get the application running, but this is now a python issue, and if I wish to proceed further I’ll start a new thread.

But I may not pursue this further … so in case anyone is curious and want to proceed from where I (possibly) gave up after running the script, then the full instructions were to send the following:


To download and install the project:
>wget -O - https://github.com/arnon-weinberg/Upscale-interpolate-STARnet/archive/master.tar.gz | tar xz
>cd Upscale-interpolate-STARnet-master
>setup
>source pytorch/bin/activate
>upscale --help

After successfully running the ‘wget’, and the ‘cd’ and ‘ksh setup’, I further note that the remaining commands can not be done precisely as posted (as last not by me given my limited knowledge (in this subject matter)). Instead I tried (from the directory “Upscale-interpolate-STARnet-master” ) which got a bit further:


oldcpu@corei7:~/Upscale-interpolate-STARnet-master>
oldcpu@corei7:~/Upscale-interpolate-STARnet-master> ksh
$
$ source pytorch/bin/activate
(pytorch) $
(pytorch) $ ./upscale --help  
* .... an output from the help menu seen here which I am not posting ...*
....        
(pytorch) $ ./upscale MVI_1002.mp4                                                                                                                                             
Extracting frames from 'MVI_1002.mp4' ...Traceback (most recent call last):
  File "./upscale", line 86, in <module>
    if   opt.scene'st'] is not None:
TypeError: 'NoneType' object is not subscriptable
(pytorch) $ 

MVI_1002.mp4 is a test video I put in the directory to test out the application.

I read “TypeError: ‘NoneType’ object is not subscriptable” is one of the most common Python errors, and it exceeds my knoweldge, and its off topic of this thread. (Likely more input is needed than what I provided in the ‘upscale’ command I sent).

Again …

My thanks again to those who pitched in to help on this thread. Again, I’ll start a new thread if I decide to pursue this further.

The problem is exactly due to bash and how it invokes external programs. The problem goes away if you use ksh to invoke this script. The script had exactly the same problem if it had /bin/bash shebang because it does not depend on which shell is invoked (except of course shell should be capable to interpret script), but how it is invoked.

The script is correct for the environment for which is was written and tested. Most of the instructions, howtos etc you find on Internet do not list exact conditions simply because their authors are not aware of them. That is normal and not lousy. Do you test every line of program you write in every possible environment?

Depends a bit on the value you give to the word ‘lousy’.

And for what it is worth, yes, I many times wrote (ksh) scripts to be executed on HP-UX, Sun-OS, AIX, …, several Linux distributions, etc. And molded the wanted environment to what was needed (like the “make the path to the script the working directory” command showed earlier).

That is of course not about “every line of program I wrote”, but that is about code that has the intention to be run by others in other environments and I assume the script we are talking about was written for that kind of usage.

It means opt.scene is undefined (or does not exist). Briefly looking at upscale code - opt.scene refers to value of argument --scene and it does not check whether this argument is defined before using it.

But yes, this goes off topic here.

What makes you think this was the intention? The intention of this blog post was to document what author has done. And if you look at examples, every invocation of upscale has --scale option, so apparently author never ever hit this trivial bug in his program.

I am not talking about the off-topic --scale option. I am talking about the setup script. Wasn’t that made for usage “everywhere”. When not then I am not understanding why it is run at all.

From “man bash”:
**
ARGUMENTS**
If arguments remain after option processing, and neither the **-c **nor the **-s **option has been supplied, the first argument is assumed to be the name of a file containing shell commands. If **bash **is invoked in this fashion, **$0 **is set to the name of the file, and the positional parameters are set to the remaining arguments.

I presume #!/bin/bash and #!/bin/ksh are ignored in this case.