return the search matches if code is not equal to zero

[priyankapinku]

description :

When the user searches for a file in the IFS browser without specifying a path, the FindIFS function searches across all directories. However, for some directories the user does not have permission access, resulting in "Permission Denied" errors. Because of these errors, the command returns a non-zero exit code, and currently the overall result is treated as failure even when the file is successfully found in accessible directories. Due to this, valid search results are not being displayed to the user.

Changes:

I have added the condition to check for code is not equal to zero and stdres data

Checklist

• [ x] have tested my change
• [x ] have created one or more test cases
• updated relevant documentation
• [x ] Remove any/all console.logs I added
• have added myself to the contributors' list in CONTRIBUTING.md

reference PR: #3114

[buzzia2001]

Hu @priyankapinku ,
Your change makes sense, but we can't ignore stderr in this case, so in order for the PR to be approved, it must also include a warning message in case stderr contains any output

[rapra41]

Hi @buzzia2001 ,

My understanding is that we were not passing any stderr output before, and we were also not displaying such errors to the user. The search operation has traditionally returned only the matching file paths (hits).

For example, if a user searches for a filename and one directory contains a file with restricted permissions while another directory contains a valid match, surfacing permission-denied errors alongside the search results could make the output look noisy or confusing. Previously, users would simply receive the matching file paths.

Even if we pass warnings/error, those errors are not being surfaced in the IDE UI, and the behavior remains the same from the user's perspective—the search returns the matching file paths without displaying permission-related errors.

Here is a snapshot of the errors and results

[buzzia2001]

Hi @buzzia2001 ,

My understanding is that we were not passing any stderr output before, and we were also not displaying such errors to the user. The search operation has traditionally returned only the matching file paths (hits).

For example, if a user searches for a filename and one directory contains a file with restricted permissions while another directory contains a valid match, surfacing permission-denied errors alongside the search results could make the output look noisy or confusing. Previously, users would simply receive the matching file paths.

Even if we pass warnings/error, those errors are not being surfaced in the IDE UI, and the behavior remains the same from the user's perspective—the search returns the matching file paths without displaying permission-related errors.

Here is a snapshot of the errors and results

Hi @rapra41
my request is not to make a warning parser, just to show a banner only if there are any, then if you want to put the detail in the banner even better...

[buzzia2001]

Review the condition please

[SanjulaGanepola]

@rapra41 In the screenshot you had sent me, it is definitely not very readable in the UI (as shown below). Also this is just a search tool so the user does not need all this detailed information (they can still access it in the Code for IBM i output channel if needed). If we do still think it is beneficial to show the count, I would suggest something like:

179 file(s) contain(s) 'hello' — Permission denied to 5 file(s)

[rapra41]

Hi @buzzia2001,
Here is the updated PR #3259 . As the original author is no longer with IBM, I have updated the PR and taken ownership of it.
Could you please review it?

Thanks!

[buzzia2001]

Hi @buzzia2001,

Here is the updated PR #3259 . As the original author is no longer with IBM, I have updated the PR and taken ownership of it.

Could you please review it?

Thanks!

So, can i close this one?