vscode-bash-debug
vscode-bash-debug copied to clipboard
rogalmic
unrecognized option -- -
Executables
Version of bash-debug: bash-3.1-0.09
Output of following commands (on windows, execute them in Command Prompt or PowerShell):
where bash:
what? Do you mean which bash?
code --version:
1.24.1
24f62626b222e9a8313213fb64b10d741a326288
x64
bash -c 'uname -a; for P in bash bashdb cat mkfifo pkill; do echo ---; which -a $P; command $P --version; done':
Darwin EEDWARDSLT-MAC.local 17.6.0 Darwin Kernel Version 17.6.0: Tue May 8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEASE_X86_64 x86_64
---
/bin/bash
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
Copyright (C) 2007 Free Software Foundation, Inc.
---
/usr/local/bin/bashdb
Bourne-Again Shell Debugger, release bash-3.1-0.09
Copyright 2002, 2003, 2004, 2006, 2007 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
bashdb: cannot read program to debug: Bc:hL:nqt:T::x:XYV.
---
/bin/cat
cat: illegal option -- -
usage: cat [-benstuv] [file ...]
---
/usr/bin/mkfifo
mkfifo: illegal option -- -
usage: mkfifo [-m mode] fifoname ...
---
/usr/bin/pkill
pkill: illegal option -- -
usage: pkill [-signal] [-ILfilnovx] [-F pidfile] [-G gid]
[-P ppid] [-U uid] [-g pgrp]
[-t tty] [-u euid] pattern ...
Debug output
13:03:45, 2018-6-22
From client: initialize({"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"bashdb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"})
To client: {"seq":0,"type":"response","request_seq":1,"command":"initialize","success":true,"body":{"supportsConditionalBreakpoints":false,"supportsConfigurationDoneRequest":false,"supportsEvaluateForHovers":true,"supportsStepBack":false,"supportsSetVariable":false}}
From client: launch({"type":"bashdb","request":"launch","name":"Bash-Debug (hardcoded script name)","cwd":"/Users/eedwards/Documents/dev/bash-util","program":"/Users/eedwards/Documents/dev/bash-util/bash-util/build/lib/bash-util-1.0/test","args":[],"showDebugOutput":true,"trace":true,"pathBash":"bash","pathBashdb":"bashdb","pathCat":"cat","pathMkfifo":"mkfifo","pathPkill":"pkill","__sessionId":"38047af9-b61e-4e71-bb4f-cd757dda6cbd"})
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stdout","output":"Bourne-Again Shell Debugger, release bash-3.1-0.09\n"}}
Bourne-Again Shell Debugger, release bash-3.1-0.09
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stdout","output":"Copyright 2002, 2003, 2004, 2006, 2007 Rocky Bernstein\nThis is free software, covered by the GNU General Public License, and you are\nwelcome to change it and/or distribute copies of it under certain conditions.\n\n"}}
Copyright 2002, 2003, 2004, 2006, 2007 Rocky Bernstein
This is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stderr","output":"bashdb: cannot read program to debug: Bc:hL:nqt:T::x:XYV.\n"}}
bashdb: cannot read program to debug: Bc:hL:nqt:T::x:XYV.
Details
bashdb works fine when ran from the command line directly:
→ bash --debugger -- test
(/Users/eedwards/Documents/dev/bash-util/build/lib/bash-util-1.0/test:3):
3: source ./bash-util.bash
bashdb<0> q
I got further, still having issues.
I'm running on OSX which uses BSD and doesn't support long getopt
Had to run the bashdb installation using ./configure --disable-getopt which got me past the initial error message.
However, now when running I get this:
/usr/local/bin/bashdb: unrecognized option -- -
Use --help for option help. Terminating...
debug output
13:16:19, 2018-6-22
From client: initialize({"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"bashdb","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-us"})
To client: {"seq":0,"type":"response","request_seq":1,"command":"initialize","success":true,"body":{"supportsConditionalBreakpoints":false,"supportsConfigurationDoneRequest":false,"supportsEvaluateForHovers":true,"supportsStepBack":false,"supportsSetVariable":false}}
From client: launch({"type":"bashdb","request":"launch","name":"Bash-Debug (simplest configuration)","program":"/Users/eedwards/Documents/dev/bash-util/build/lib/bash-util-1.0/test","showDebugOutput":true,"trace":true,"args":[],"cwd":"/Users/eedwards/Documents/dev/bash-util","pathBash":"bash","pathBashdb":"bashdb","pathCat":"cat","pathMkfifo":"mkfifo","pathPkill":"pkill","__sessionId":"15d52173-23da-4ed4-8d58-9d1ee84e2b91"})
To client: {"seq":0,"type":"event","event":"output","body":{"category":"stdout","output":"/usr/local/bin/bashdb: unrecognized option -- -\nUse --help for option help. Terminating...\n"}}
/usr/local/bin/bashdb: unrecognized option -- -
Use --help for option help. Terminating...
Please advise
I assume this may be due to installing it without getopt support.
Can you confirm if there is support for the short option names?
→ bashdb -h
_Dbg_usage:
bashdb [OPTIONS] <script_file>
Runs script_file under a debugger.
options:
-B basename only on source listings. (Needed in regression tests)
-h print this help
-n Don't run initialization files
-c command Run this passed command as a script
-q Quiet. Do not print introductory and quiet messages.
-L libdir set directory location of library helper file: dbg-main.inc
the default directory is: /usr/local/share/bashdb
-T tmpdir set directory location for temporary files: /tmp
-t tty set debugger terminal
-x cmdfile execute debugger commands from cmdfile
-X set line tracing
-Y set line tracing with variable expansion
-V show version number and no-warranty and exit.
Also, whenever I stop the debugging process, it doesn't seem to exit properly... I have to 'reload window' for vscode to let me run it again.
This extension was developed and tested with much newer bashdb version than:
/usr/local/bin/bashdb
Bourne-Again Shell Debugger, release bash-3.1-0.09
Is there any reason for using older bash + older bashdb?
Yes, Mac OSX runs bash 3.2.
Get Outlook for iOShttps://aka.ms/o0ukef
From: Michał [email protected] Sent: Friday, June 22, 2018 1:47:34 PM To: rogalmic/vscode-bash-debug Cc: Ethan Edwards; Author Subject: Re: [rogalmic/vscode-bash-debug] unrecognized option -- - (#70)
This extension was developed and tested with much newer bashdb version than:
/usr/local/bin/bashdb Bourne-Again Shell Debugger, release bash-3.1-0.09
Is there any reason for using older bash + older bashdb?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/rogalmic/vscode-bash-debug/issues/70#issuecomment-399543448, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Ag-68UmCHghUbqduKuQlFjYRO11t2W3fks5t_TvGgaJpZM4U0Nl7.
This is simplified command line used by extension:
bashdb --quiet --tty "${fifo_path}" -- ./debugged_script.sh
The -- separates bashdb args from script path and script args. Please show the output of this command line (omit the tty arg for now).
Hey @rogalmic thanks for your response
Here's the output:
→ bashdb --quiet -- ./test
/usr/local/bin/bashdb: unrecognized option -- -
Use --help for option help. Terminating...
I believe this confirms what I suspected, that the long option names (e.g. --quiet) are not supported.
I haven't dug into your codebase yet, so I apologize for 'taking a stab at a solution' without any real knowledge, but perhaps we could add a setting in launch.json to useShortOptionNames or similar?
Thanks in advance!
edit: also, as an amusing easter egg... with short options bashdb still prints Use --help for option help., which doesn't work! haha!
→ bashdb --help
/usr/local/bin/bashdb: unrecognized option -- -
Use --help for option help. Terminating...
:)
Maybe @wataash can help you, since I believe he is using OSX together with this vscode extension.
@eedwards-sk
On bashdb@7504a22, the behavior of getopt_long was changed, which was included on bashdb-4.0-0.4.
Could you try bashdb-4.4-0.92? (not 4.4-0.93 or later because of #69)
I think it can be installed without --disable-getopt.
I'll investigate it more from next week... :)
Thanks for the response. I must use the version I'm using. If you read the readme in the sourceforge repo for bashdb, you will see that the version of bashdb correlates to the version of bash. It's not designed to always be ran with the latest version, thus I believe a project like this would benefit from knowing how to invoke various versions.
Thanks
Get Outlook for iOShttps://aka.ms/o0ukef
From: Wataru Ashihara [email protected] Sent: Saturday, June 23, 2018 2:21:15 AM To: rogalmic/vscode-bash-debug Cc: Ethan Edwards; Mention Subject: Re: [rogalmic/vscode-bash-debug] unrecognized option -- - (#70)
@eedwards-skhttps://github.com/eedwards-sk
On bashdb@7504a22https://sourceforge.net/p/bashdb/code/ci/7504a22/, the behavior of getopts_long was changed, which was included on bashdb-4.0-0.4.
Could you try bashdb-4.4-0.92https://sourceforge.net/projects/bashdb/files/bashdb/ (not 4.4-0.93 or later because of #69https://github.com/rogalmic/vscode-bash-debug/issues/69)? I think it can be installed without --disable-getopt.
I'll investigate it more from next week... :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/rogalmic/vscode-bash-debug/issues/70#issuecomment-399645436, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Ag-68Y--xT6H5DClT5jIGaLhESja_00Rks5t_exrgaJpZM4U0Nl7.
Makes sense!
@rogalmic
Why don't we replace --quiet --tty with -q -t ?
Using short options seems to be necessary when using macOS's built-in /bin/bash (version 3.2.57, even on latest macOS, which requires an older version of bashdb).
Summary of the issue
bashdb on some environment can't parse --quiet and --tty options, thus vscode-bash-debug doesn't work.
- bashdb < 4.0-0.4 uses getopt(1) to parse arguments to
bashdb- https://sourceforge.net/p/bashdb/code/ci/e04ca4b/tree/bashdb.in
- getopt(1) in utils-linux can parse long options, whereas built-in
/usr/bin/getoptcannot (below code block below) - Recent bashdb doesn't use getopt(1), so this problem occurs only on older bashdb.
getopt(1) on linux:
$ type getopt
getopt is /usr/bin/getopt
$ getopt --version
getopt from util-linux 2.31.1
$ getopt -o Bc:hqT: --long basename,command:,help,quiet,terminal: -n 'bashdb' -- -B --command=foo -q --terminal=bar arg
-B --command 'foo' -q --terminal 'bar' -- 'arg'
getopt(1) on macOS:
$ type getopt
getopt is /usr/bin/getopt
$ getopt --version
--
$ getopt -o Bc:hqT: --long basename,command:,help,quiet,terminal: -n 'bashdb' -- -B --command=foo -q --terminal=bar arg
-- Bc:hqT: --long basename,command:,help,quiet,terminal: -n bashdb -- -B --command=foo -q --terminal=bar arg
OK, if it helps we will change that (it is quite small and safe change).
However, because of limited development resources / time release candidate testing will still be done only with newer bashdb.
I found one issue while i was testing, seems newest bashdb does not recognize -t option:
Unknown option t. Use -h or --help to see options.
version, help:
bashdb, release 4.4-0.94
-----
Usage:
bashdb [OPTIONS] <script_file>
Runs bash <script_file> under a debugger.
options:
-h | --help Print this help.
-q | --quiet Do not print introductory and quiet messages.
-A | --annotate LEVEL Set the annotation level.
-B | --basename Show basename only on source file listings.
(Needed in regression tests)
--highlight {dark|light} Use dark or light background ANSI terminal sequence
syntax highlighting
| --no-highlight
Don't use ANSI terminal sequences for syntax
highlight
--highlight | --no-highlight
Use or don't use ANSI terminal sequences for syntax
highlight
--init-file FILE Source script file FILE. Similar to bash's
corresponding option. This option can be given
several times with different files.
-L | --library DIRECTORY
Set the directory location of library helper file:
/usr/share/bashdb/dbg-main.sh
-c | --command STRING Run STRING instead of a script file
-n | --nx | --no-init Don't run initialization files.
-S | --style STYLE Run use pygments STYLE for formatting source code
--tty | --terminal DEV Set to terminal in debugger output to DEV
DEV can also be &1 for STDOUT
-T | --tempdir DIRECTORY
Use DIRECTORY to store temporary files
-V | --version Print the debugger version number.
-X | --trace Set line tracing similar to set -x
-x | --eval-command CMDFILE
Execute debugger commands from CMDFILE.
Any ideas how to tackle that? I would not like to make any if/else logic for supporting older version, at least not preferably.
Any updates on this by chance?
If/else for supporting older versions doesn't seem that bad IMO since older versions do not change, and bash version is linked to bashdb version.
Would love to be able to use this plugin. Let me know if there's anything I can do to help.
Can you check if this old bashdb by any chance supports somehow --tty or --terminal option?
This is a bit problematic, since your version supports only short options, but there is no -t for terminal which is required by this plugin (utilized for core functionality).
@rogalmic
Here's the help output from bashdb. Looks like there is a -t tty option:
→ bashdb -h
_Dbg_usage:
bashdb [OPTIONS] <script_file>
Runs script_file under a debugger.
options:
-B basename only on source listings. (Needed in regression tests)
-h print this help
-n Don't run initialization files
-c command Run this passed command as a script
-q Quiet. Do not print introductory and quiet messages.
-L libdir set directory location of library helper file: dbg-main.inc
the default directory is: /usr/local/share/bashdb
-T tmpdir set directory location for temporary files: /tmp
-t tty set debugger terminal
-x cmdfile execute debugger commands from cmdfile
-X set line tracing
-Y set line tracing with variable expansion
-V show version number and no-warranty and exit.
Edit: ah, I see, I think you're saying they changed from -t to --tty. This makes sense, since --tty is not a valid short name when getopt is disabled.
Has someone built newer bashdb with getopt disabled to see if --tty becomes -t? Then maybe the if/else logic could be based on the build type instead of the version.
Some systems have trouble with GNU long options (getopt). For those
systems you may want to add --disable-getopt to configure.
Yes, the only option seems to be if/else. (actually we also might add optional parameters to config, so "-tty" could be changed to whatever needed)
Please check attached vsix plugin (uninstall the store version beforehand, then use "Install from VSIX" option in extensions pane) bash-debug-0.2.0.vsix.zip
Hey thanks @rogalmic
This got me further! This is very exciting!
I do get some console output that I don't get when running bashdb in the cmd line.
When running, now I got:
usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file
and it starts the debugging process
Edit: Re-running the debug process I'm not getting that message again.
Pardon my language, but this is FUCKING INCREDIBLE!! I can't believe I'm stepping through bash code in a visual editor right now. This is so cool!
Let me know if you get an official version with support otherwise I'll keep playing with this for now.
I've noticed that the local variables don't appear to be showing up as I'd expect, as stepping through each function in the stack, they don't seem to change or represent the current location. Is this expected?
edit:
also, the
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file
showed up again after hovering around a few variables while running
I can repro the error output from above reliably now.
_bash_util__list__contains 'processed_positionals' "${positional}" &&
if I hover over the 'processed_positionals' part of the command, I get this output:
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 838: unexpected EOF while looking for matching `''
/usr/local/share/bashdb/dbg-cmds.inc: eval: line 839: syntax error: unexpected end of file