Hello,
I have started using the plugin with my PHPStorm IDE. I have set up a configuration but whenever I run it I always have a double dash “–” appearing between the script name and the parameters I give which nullifies all parameters.
Thanks if you can offer help!
I’m sorry for the difficulties using the plugin.
Could you post a screenshot of the run configuration? That would help to understand what might be be wrong. Thanks!
Thanks!
Are you perhaps running the script under a debugger? Or, how do you launch the script? How to start and stop the Debugger – BashSupport Pro
“Debug” only situation I can think of where a -- is automatically added to the command line to support custom arguments, but it shouldn’t change the arguments received by your script. man bash:
– signals the end of options and disables further option processing. Any arguments after the – are treated as filenames and arguments. An argument of - is equivalent to --.
But there seems to be a bug, I suppose. The following should help me:
Thank you!
PhpStorm 2021.3.3
Build #PS-213.7172.28, built on March 17, 2022
Licensed to USU Software AG / Stephen Hyde
Subscription is active until June 24, 2022.
Runtime version: 11.0.14.1+1-b1751.46 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.4.0-104-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 8000M
Cores: 12
Registry:
debugger.watches.in.variables=false
run.processes.with.pty=TRUE
Non-Bundled Plugins:
org.sonarlint.idea (6.5.1.43866)
com.jetbrains.darkPurpleTheme (1.3)
com.intellij.ideolog (203.0.27.0)
zielu.gittoolbox (212.8.8)
de.espend.idea.php.annotation (8.0.0)
com.kalessil.phpStorm.phpInspectionsEA (4.0.7.1)
NEON support (0.5.1)
com.jetbrains.upsource (2020.1.1990.12)
ru.adelf.idea.dotenv (2022.1)
pro.bashsupport (2.1.5.213)
Current Desktop: ubuntu:GNOME
Ubuntu 20.04
plugin: 2.1.5.213
Thank you for the details!
Unless you want to debug the script, using Run prepare-release instead of Debug prepare-release should help (via context menu or by clicking the green arrow instead of the debug icon).
I’m not sure why -- breaks script execution, because it’s supposed to be a standard Bash feature. I’ll debug that on Ubuntu and release an update of 2.1.x which doesn’t add -- if I find that debugging is still working on all supported operating systems and versions of Bash.
Yes debugging is the important part for me in this case
Isn’t it the case though that – prevents all further parameters being used, and if all parameters by default in debugging mode come after the – then they are all useless?
No, AFAIK -- tells Bash to stop parsing the following arguments as Bash arguments, they’re then sent as-is to the script.
Could you explain what you’re observing in the script, which breaks under the debugger?
Could you run this script with Debug and the same arguments you’re passing to your other script:
#!/usr/bin/env bash
echo "Script parameters:" "$@"
With Bash 5, I’m seeing the arguments as expected:
There may be minor differences when a script is executed under a the debugger. With some more context, I might be able to provide a workaround.
Thanks!
Interesting, script parameters are shown:
Script parameters: -p -v -73 -s v4_6_step_2 smarttrack-developer
It’s hard to say what I see in the script. Line 79 which is where it says the error comes from is actually the middle of a very large variable that shows parameters for the script that is echoed out elsewhere
Thanks for testing! Unfortunately, this problem seems difficult to find. It’s still possible that it’s caused by the debugger, but I probably won’t be able to fix it without a better understanding what’s going on.
You could try to add a breakpoint on line 78 or 79 and then evaluate expressions to find out more about what it’s doing and what might be wrong.
Is the error Error while on line 79 printed by your script? I don’t think it’s emitted by the debugger itself or BashSupport Pro.
Could you perhaps describe which commands are executed on line 79 or what that line is doing? Feel free to email that to mail@bashsupport.com if you don’t want to post it here.
Thanks!
That’s the crazy thing, between line 35 and 103 there is only a variable being set to a multi-line string (68 lines).
I would agree that the error is being output by the script itself and not the debugger.
It’s been a while since I raised this issue however I’ve been doing a large amount of refactoring on the affected script lately and I might have a case that you can use to test. The following code run with the debug button (i.e. no other custom configuration set) gives me the same error as before:
#!/bin/bash
errorexit() {
local msg="${1}"
echo “${0}: Error while ${msg} on line ${BASH_LINENO[$i]}” >&2
trap ERR
exit 1
}
trap errorexit ERR
gives:
/bin/bash /home/adishyde/.local/share/JetBrains/PhpStorm2022.1/bashsupport-pro/bashdb/5.0/bashdb --quiet --no-highlight --library /home/adishyde/.local/share/JetBrains/PhpStorm2022.1/bashsupport-pro/bashdb/5.0/share/bashdb --tty_in DBG_PTY --tty DBG_PTY /home/adishyde/.config/JetBrains/PhpStorm2022.1/scratches/scratch_13.sh
hi
/home/adishyde/.config/JetBrains/PhpStorm2022.1/scratches/scratch_13.sh: Error while on line 79
Process finished with exit code 0
Running the above without debugging produces:
/bin/bash /home/adishyde/.config/JetBrains/PhpStorm2022.1/scratches/scratch_13.sh
Process finished with exit code 0
Given that the script only has 10 lines it’s interesting that the error occurs on line 79.
Hope this helps.
Thanks for the snippet! That helped to reproduce it, I’ll investigate and hope to be able to provide a fix. It’s most likely something internal of bashdb.
@shusu Here’s the result of my investigation.
First of all, the ERR trap function was printing the source, where errorexit was defined.
If you pass $BASH_SOURCE as part of the code called as trap handler, then you could capture the file, where the error occurs.
With the fix, it’ll print that the erroneous file is /home/user/.local/share/JetBrains/Toolbox/apps/IDEA-U/ch-3/222.3345.16.plugins/bashsupport-pro/bashdb/5.0/share/bashdb/lib/hook.sh, which is part of bashdb.
Lines 79 and 80 of that file are:
shopt nullglob > /dev/null
typeset -i _Dbg_old_set_nullglob=$?
The exit code of shopt is non-zero if nullglob isn’t set, which then triggers your ERR trap, which then terminates the script.
This could be fixed in bashdb itself, but there are more than a few lines like this.
Changes to upstream bashdb would take a while and have to be made carefully. I’m not sure yet if I’ll do that.
I recommend the following changes to ignore errors, which are part of the bashdb sources.
Does this work for you?
#!/bin/bash
errorexit() {
local file="$1"
local line="$2"
local error="$3"
echo "$file: Error $error on line $line" >&2
trap ERR
if [[ "$file" != *'/bashdb/'* ]]; then exit 1; fi
}
trap 'errorexit ${BASH_SOURCE[0]} $LINENO $?' ERR
Yep that fixed it thanks!