Author Topic: Does webbatch have a problem with linked paths?  (Read 354 times)

bottomleypotts

  • Jr. Member
  • **
  • Posts: 81
Does webbatch have a problem with linked paths?
« on: December 08, 2022, 08:15:24 pm »
I don't seem to be able to "call" a subroutine from webbatch. The file exists in the path, however the path has been created with a "mklink /D".

td

  • Tech Support
  • *****
  • Posts: 4233
    • WinBatch
Re: Does webbatch have a problem with linked paths?
« Reply #1 on: December 09, 2022, 08:14:41 am »
Not sure what you mean by calling a subroutine since calling a subroutine does not in and of itself involve accessing a file. But assuming you are referring to calling a second script from a running script, WebBatch does not have any "problems" with symbolic links. Your problem is more likely than not file/directory permissions related. Web server processes run with very restricted user account permissions.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

bottomleypotts

  • Jr. Member
  • **
  • Posts: 81
Re: Does webbatch have a problem with linked paths?
« Reply #2 on: December 09, 2022, 06:28:26 pm »
Not sure what you mean by calling a subroutine since calling a subroutine does not in and of itself involve accessing a file. But assuming you are referring to calling a second script from a running script, WebBatch does not have any "problems" with symbolic links.

Yes. That is why I enclosed the "call" in quotations, so that readers understood that I was using the call function - ie. Call ( filename, parameters ). Sorry, don't know how I would make that any more clearer.

Your problem is more likely than not file/directory permissions related. Web server processes run with very restricted user account permissions.

The first script appears to be running correctly, and is called from the same linked path. The subsequent call is being called from the same location. And yes, I have checked file permissions. I can fileget() the file. I cannot call() the file.

The error message is: 102:  Specified menu/batch file not found.


td

  • Tech Support
  • *****
  • Posts: 4233
    • WinBatch
Re: Does webbatch have a problem with linked paths?
« Reply #3 on: December 10, 2022, 04:10:15 pm »

Quote
Yes. That is why I enclosed the "call" in quotations, so that readers understood that I was using the call function - ie. Call ( filename, parameters ). Sorry, don't know how I would make that any more clearer.

There are a lot of ways to make something more straightforward. For example, say you are using the "call" function to load a second script. The term "subroutine" has several meanings in WinBatch including making a"call" to a user-defined-subroutine.

Quote
The first script appears to be running correctly, and is called from the same linked path. The subsequent call is being called from the same location. And yes, I have checked file permissions. I can fileget() the file. I cannot call() the file.

The error message is: 102:  Specified menu/batch file not found.

It would have been useful to provide that information in your original post. However, I am not sure what is causing the error but I doubt it is because of a symbolic link since the call function and the fileget function open files for reading in the same way. Are you using full paths or relative paths for each function?
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

bottomleypotts

  • Jr. Member
  • **
  • Posts: 81
Re: Does webbatch have a problem with linked paths?
« Reply #4 on: December 10, 2022, 09:10:59 pm »
I am using a variable to test. It has the full path to the file included. Both the "call" function and the "fileget" function use the variable.

td

  • Tech Support
  • *****
  • Posts: 4233
    • WinBatch
Re: Does webbatch have a problem with linked paths?
« Reply #5 on: December 11, 2022, 07:57:25 am »
Don't think we can help you. We tried to reproduce your problem but could not. The Call function does perform a search for the target file and the FileGet function does not. Another difference is that FileGet supports extended paths and Call does not. Also, FileGet respects IntControl 39 settings, and Call always uses "Read Share mode" to open files. Otherwise, both Call and FileGet use the same internal function to open files.

For what it is worth, the Call function returns a 1400 error when it cannot find the file in the function's first parameter.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade