Command system not found

[kraudy]

Hi, i'm having this problem on the test server that i have at work: The object browser filters don't work because it says that the library does not exist. Which is weird because i can add them to the library list. I have like 10 filters of 10 different libraries and it says that none of them exists!

Looking at the ouput console it says something like this (i can't show an image because of work rules and stuff and even github is blocked, you know how it goes): { "code":127, "signal": null, "stdout": "", "stderr": "qsh 001-0019 error finding command system. Acces route or directory does not exist" }

I don't know if the architecture people changed something but we have a development server and on that one it works fine.

Any idea to fix this? It looks something like the system command location is not in the path when the qsh command is executed but im guessing here.

[worksofliam]

That is totally weird.

Are you able to SSH into the system and try which system?

For example, this is what I get:

-bash-5.1$ which system
/usr/bin/system

[kraudy]

Yeah @worksofliam , i can log in but can't work on any source since when i try opening the object filter it says that the library don't exist Here is the output of which system: /QOpenSys/usr/bin/system

[sebjulliand]

@kraudy can you share the content of your ~/.bashrc file if you have one?

[kraudy]

@sebjulliand this is the .bashrc export PATH=/QOpenSys/pkgs/bin:$PATH Also, i have a .profile PATH=/QOpenSys/pkgs/bin:$PATH export PATH PASE_PATH bash

[kraudy]

@worksofliam @sebjulliand any other idea? The arch people say they didn't change anything :/

[sebjulliand]

@worksofliam @sebjulliand any other idea? The arch people say they didn't change anything :/

They always say that 😁 No other idea so far...what if you run system "DSPLIBL" from a PASE Terminal opened from VSCode? Does it run OK?

[kraudy]

@sebjulliand yep, it runs ok, i even tried adding again the qshell library with cl addlible QSHELL and trying cl CALL SYSTEM this works, but i don't know if that gives any useful info

[SJLennon]

@kraudy

It looks something like the system command location is not in the path when the qsh command is executed but im guessing here.

Really wild guess on your guess: Try DSPCMD QSH. Is it a proxy for QSHELL/QSH?

                         Display Command Information                     

Command  . . . . . . . :   QSH           Library  . . . . . . . :   QSYS 

Target command . . . . . . . . . . . . :   QSH                           
  Library  . . . . . . . . . . . . . . :     QSHELL                      
Text . . . . . . . . . . . . . . . . . :   Start QSH                     

Current proxy chain  . . . . . . . . . :   QSYS/QSH                      
                                           QSHELL/QSH                    

[kraudy]

@SJLennon the output of DSPCMD QSH is exactly like your image

[chrjorgensen]

@kraudy Hello - some thoughts that may help in debugging this:

• does the IFS BROWSER view work?

If no, then something is wrong in your PASE setup. Verify your bash startup files and note, that Code for IBM i uses an interactive non-login shell and .profile is not used.

If yes, your PASE shell is working normally. Then,

• does the USER LIBRARY LIST view work normally?

I would not expect this view to work - since it uses the same QSHELL commands as the Object browser to retrieve IBM i object information.

For further debugging, inspect carefully the OUTPUT tab for Code for IBM i, Any suspicious messages in here? There will be a lot of information here, so you could clear the pane before expanding the filter in the Object browser, to avoid having to search through too much output.

[kraudy]

@chrjorgensen Hi, the IFS BROWSER view works just fine The USER LIBRARY LIST also works just fine Here is the transcribed output of the pane after expandind the filter in the Object browser /home/MYUSER: /QOpenSys/usr/bin/qsh

system "CHKOBJ OBJ(QSYS/MYLIB) OBJTYPE(*LIB) AUT(*NONE)"

{ "code" 127, "signal": null, "stdout": "", "stderr" : "qsh: 001-0019 Error finding command system. Not a valid route or directory" }

[kraudy]

I would not expect this view to work - since it uses the same QSHELL commands as the Object browser to retrieve IBM i object information.

Given what u said. It looks like qsh is executing most commands OK. I don't know if codefori uses the same system command for the LIBRARY LIST. That would be even more weird.

[kraudy]

Maybe this helps.

I tried this from a PASE Terminal opened from VSCode This gives no error system "CHCKOBJ OBJ(QSYS/MYLIB) OBJTYPE(*LIB) AUT(*NONE)" So it founds the system command

But this gives the same error that vscode shows when openning the object browser filter qsh -c "system \"CHCKOBJ OBJ(QSYS/MYLIB) OBJTYPE(*LIB) AUT(*NONE)\"" qsh: 001-0019 Error finding command system. No such route or directory when executed this way, it seems to not find the system command, which is what codefori uses

[kraudy]

From the green screen

this works fine QSH CMD(' /QOpenSys/usr/bin/system "CHKOBJ OBJ(QSYS/MYLIB) OBJTYPE(*LIB) AUT(*NONE)" ')

This gives the same error QSH CMD('system "CHKOBJ OBJ(QSYS/MYLIB) OBJTYPE(*LIB) AUT(*NONE)" ')

[kraudy]

Tryining this on the development server works fine QSH CMD('system "CHKOBJ OBJ(QSYS/MYLIB) OBJTYPE(*LIB) AUT(*NONE)" ') checking the PATH env variable i get this: /usr/bin:./QOpenSys/usr/bin:/QOpenSys/pkgs/bin

On the test server (the one that gives the error of command not found) PATH env looks like this: /QOpenSys/pkgs/bin

I think the env PATH default configuration of when a new qsh terminal is executed on our test server was changed. But i don't know if that should affect vs code when it executes the qsh -c command

system is located at /QOpenSys/usr/bin/system

[chrjorgensen]

PATH should NOT be /QOpenSys/pkgs/bin only!

Seems like there's an error in your bash startup file - the normal setup is to prepend the IBM OSS package directory to the PATH environment variable like this:

export PATH=/QOpenSys/pkgs/bin:$PATH

to have the yum binaries available as first priority and the PASE binaries as second priority.

Please check the export PATH= lines in your bash startup files! The error is definitely in one of these lines...

[kraudy]

@chrjorgensen That is not the PATH of my pase env. That PATH is fine. If it was not ok, just running system from PASE would give command not found. The PATH i was referring to was the PATH that is set when you execute QSH CMD or qsh -c If i do echo $PATH from pase, there it is /QOpenSys/usr/bin/system /QOpenSys/pkgs/bin and the other paths

[kraudy]

here is the contents of the .bashrc i showed earlier

@sebjulliand this is the .bashrc export PATH=/QOpenSys/pkgs/bin:$PATH Also, i have a .profile PATH=/QOpenSys/pkgs/bin:$PATH export PATH PASE_PATH bash

[kraudy]

I should mention that this problem is not only mine, all my team have the same problem

[chrjorgensen]

@kraudy What do you get when you run this command in PASE:

qsh -c 'echo $PATH'

I get /usr/bin:.:/QOpenSys/usr/bin - which is the default value for PATH, when QSHELL is invoked: https://www.ibm.com/docs/en/i/7.3?topic=language-shell-variables

Something is definitely messing with your PATH in QSHELL - maybe you can find the answer in the QSHELL documentation?

[kraudy]

@chrjorgensen i get this: /QOpenSys/pkgs/bin:/QOpenSys/usr/bin:/usr/ccs/bin:/QOpenSys/usr/bin/X11:/usr/sbin:.:/usr/bin which is interesting because you can see /QOpenSys/usr/bin wich is the path of which system but if i run qsh -c "system" then i get command not found :/

[chrjorgensen]

@kraudy Also, I don't understand your .profile content: PATH=/QOpenSys/pkgs/bin:$PATH export PATH PASE_PATH bash.

Is this all in one line? Or are newlines missing in your copy-paste?

I tested creating a .profile file like yours on my system - and it didn't affect the output from qsh -c echo $PATH', which is expected since the .profile is not run by the qsh PASE command. So your .profile seems not to be the problem...

[kraudy]

@chrjorgensen the .profile is like this from seiden group How to Set the PATH to Open Source on IBM I

[kraudy]

i thought it may be permission but /QOpenSys/usr/bin/system is a soft link with 777 and the actual location /QOpenSys/QIBM/ProdData/OS400/PASE/bin/system has 755 so it should be ok

[kraudy]

Here is somethin interesting to note

If i execute qsh -c "echo $PATH" from my bash terminal, it heredates (i assume because of Fork?) the actual PATH and give the list with the usual PATH's but the system command still can't be found (which is weird)

if i execute only qsh from my bash terminal, and the i do echo $PATH then i only get this /QOpenSys/pkgs/bin

This last PATH seems to be the env from which the system command is tryinig to be exectued every time that it says "not command found" (which makes more sense)

[kraudy]

if i execute only qsh from my bash terminal, and the i do echo $PATH then i only get this /QOpenSys/pkgs/bin

If i do this on the development server (the one on which the Object Filter view is working fine). I get this: /usr/bin:.:/QOpenSys/usr/bin:/QOpenSys/pkgs/bin and then if i execute system the command is found, which makes sense

[chrjorgensen]

@kraudy This problem is on your test server, and we fromoutside can only guess as to why it acts like this when running qsh from PASE. Your best bet is to talk to your system admin and show the problem.

Sorry for not being able to help any further...

[kraudy]

@chrjorgensen The problem is that they don't even know cuz i already asked them and they said they didn't change anything :/

[SJLennon]

@kraudy FWIW: I had problems that some commands would fail on PUB400.COM. After fighting with it for quite a while I finally got an answer on Ryver. Turned out that 4 objects were missing in /QOpenSys. Suggestion to find the problems was: "you could do CHKPRDOPT for PASE (SS1 opt 33 IIRC)".

There was a long discussion on Rvyer: https://ibmioss.ryver.com/index.html#posts/4040251.

It digressed into other topics, but the interesting bit is at "Kevin Adler Tue Jan 16 at 12:17pm"

Don't know if this is relevant to your problem, but trying CHKPRDOPT is unlikely to hurt. Though probably the sysadmin will need to run it.

[kraudy]

@SJLennon Thanks, I'll try it.

[kraudy]

@worksofliam @SJLennon @chrjorgensen is there a way that if the command system is executed and not found (which is something that should not happen) then codefori could do something like a which system and add the route (which should be /QOpenSys/usr/bin) to the PATH or try the full command route like /QOpenSys/usr/bin/system, similar to when it executes /QOpenSys/usr/bin/qsh ?

[chrjorgensen]

@kraudy Your case is unique and about a misconfigured system. We have not seen any other reports of an issue like this, and coding for such a special case does not make sense.

Since this is a QSHELL misconfiguration, maybe a CHKPRDOPT for QSHELL (CHKPRDOPT PRDID(5770SS1) OPTION(30) DETAIL(*FULL)) would show something - but I wouldn't bet on it, since this is a configuration issue and not a product issue...

You can fix this

• the correct way by creating a support case at IBM and have them help figuring why your QSHELL PATH is changed like this.
• the wrong way by creating a symlink system in /QOpenSys/pkgs/bin pointing to /QOpenSys/usr/bin/system.

If you don't fix this, other applications than Code for IBM i could be hurt if they use QSHELL and expect the path to give access to PASE commands and not just the commands installed by yum. Having a QSHELL PATH that only includes PASE open source utilities and not also PASE system utilities is a very bad setup!

Your system is in a bad state, and I'm wonder why no-one knows what has changed and cause this issue. They have two systems - one working and one not working - so it should be easy to compare the two systems to find the difference - or just copy the setup from the working system to the non-working system.

[kraudy]

@chrjorgensen Here is the first point. Most people at my company uses RDI, only a Few use VsCode (something that me and others are pushing). So this problem is only for the Few that use CodeForIBMi and dare i say, the few that know what AIX, PASE, QSH and PATH are (from asking questions, i know for a fact the the sysadmin is not clear about those, because they have not need them before).

Now, the second point. The test server is in our country, so i can talk to the sysadmin about this and that but he does not quite get it. I already told him: this is happening when a new QSH terminal is openning, something changed the previous PATH, this route should be in the PATH, the system command is not found, this is the right value that PATH has in the development server, etc (Look carefully here, to understand what i said, he has to know what a QSH terminal is, what PATH is and what the system command is)

And the third point. The development server has its own sysadmin and is on another country, so i can't talk to him, and sysadmin don't talk to other sysadmin, at least not here. So it would be my task to start asking about who he is, and then asking if he knows how the configuration is made (hoping that he knows)

Given said that. i'll try CHKPRDOPT PRDID(5770SS1) OPTION(30) DETAIL(*FULL)) maybe this monday. If i get nothing out of that, then i'll try contacting the other sysadmin, after that, it would be creating a support case and in the last case, creating the symlink

Note: i also haven't been able to find where is the configuration file for the default PATH of a new QSH terminal to just copy it, because i also thought about that.

[SJLennon]

@kraudy

A couple of weeks ago you said

@sebjulliand this is the .bashrc
export PATH=/QOpenSys/pkgs/bin:$PATH
Also, i have a .profile
PATH=/QOpenSys/pkgs/bin:$PATH export PATH PASE_PATH bash

What is that final "bash" doing at the end of your .profile? Assuming the above isn't all on one line, it still doesn't seem like the last line should be "bash". Though I don't know if this makes any difference to anything.

I don't know where the default PATH is set on the IBM i. You might look at /etc/environment and/or /etc/profile or a .env file in your home directory. Honestly, I don't know if these have any impact, but I found references to them here in AIX documentation., but it is similar to Customizing Qshell...

Got no other thoughts, sorry.

[kraudy]

@SJLennon the last "bash" only executes the bash terminal because the default was the qsh terminal, as you said, that does not change anything. I'll look at the documentation. Thanks

[chrjorgensen]

@kraudy This is not how you set the shell...!

Use the chsh command to set the default shell for the user. Don't put it into any start scripts.

[kraudy]

@chrjorgensen i've already done that, just that i haven't change the script. Nothing important.

[chrjorgensen]

It's just that we've seen quite a few cases where the startup script caused strange errors...