Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work in MacOS stock bash. Requires macports or brew. #1

Open
ghost opened this issue Aug 24, 2022 · 5 comments
Open

Does not work in MacOS stock bash. Requires macports or brew. #1

ghost opened this issue Aug 24, 2022 · 5 comments
Labels
enhancement New feature or request

Comments

@ghost
Copy link

ghost commented Aug 24, 2022

I have reproduced this issue on both

  • Intel Macbook Pro + USB Serial Prolific
  • M1 Macbook Pro + USB Serial FTDI
    Connected to a TPDD1, with factory cable

The script starts, asks which port to use (btw auto detect also does not work), then nothing happens.
The behaviour is the same even if you don't connect anything on the serial side ( eg no : TDPP at all)

Debug 1 or 2 says nothing either.

If your CTRL-C to exit the script, the script says it was at line 524 (if that info helps maybe...)

Cable setup is OK , serial adapters work & are supported, TPDD works, and not the cause of the problems. I can talk to my TPDD with the same cables and setup using Windows 11 virtual machin under Parallels and a Windows TPDD Client.

@bkw777
Copy link
Owner

bkw777 commented Aug 24, 2022

It's working for me on Monterey. But I see now that if I force it to use the bash that ships with osx, it doesn't work.

Please try installing bash from macports.
(Or brew, but if you don't already have a preference then I suggest macports over brew for being the more correct system despite brew being more popular, but either should work fine.)

In the mean time I'll see if it's possible to make it work with the stock bash. It's old but not that old. I didn't think I was relying on any bash 4.x features, but this thing is a tour-de-force of fancy bash tricks, so, yeah it could be some gimmicky parts are a bit too gimmicky ;)

I was thinking it sounded like maybe permissions/security settings, but when I forced it to use the stock bash just now I immediately hit one thing that is probably a fancy syntax problem not a security problem. The routine that tries to present a list of likely tty devices to pick from, fails to see the cu.* devices and falls back to listing all tty*. But under the stock bash, the cu.* devices are visible and listable, so it's probably something with the fancy way that routine uses globbing and brace expansions and array ops rather than permissions.

The only other two potential problems will be permissions to run stty on the tty device, and mkfifo to create a file in /tmp

@bkw777 bkw777 changed the title Script does not work on MacOS (at least Monterey) Does not work in MacOS stock bash. (works with macports or brew) Aug 25, 2022
@bkw777 bkw777 added the enhancement New feature or request label Aug 25, 2022
@bkw777
Copy link
Owner

bkw777 commented Aug 25, 2022

I'm going to make it a todo to try to downgrade the code until it works in the stock bash, because that will make it far more handy.

I might as well replace "make install" with another script too since it's a bit ridiculous to make a bash script for the purpose of having no dependencies, and then require xcode just to copy it somewhere.

@bkw777 bkw777 changed the title Does not work in MacOS stock bash. (works with macports or brew) Does not work in MacOS stock bash. Requires macports or brew. Aug 25, 2022
@bkw777
Copy link
Owner

bkw777 commented Aug 26, 2022

The blow-by-blow may not be exactly fascinating, but, yeah there turns out to be a lot of bash version compatibility stuff.

The first thing is right off the bat, the part that detects the OS fails. It doesn't like the ",," in "${OSTYPE,,}" which converts the value to all lower case, which makes it a little simpler to test for matches.

So because of that, it doesn't go into macos mode, and that causes the tty list to make a bad assumption that the tty is probably /dev/tty*something. That is the only reasonable fall-back assumption when all else failed, because it's not helpful to just list all device nodes (then again, maybe that's exactly what I should do in that case). Anyway this causes the problem that the /dev/cu.* devices are not presented in the list to choose from. So you end up selecting the equivalent tty.* device, but those are actually wrong you need to use the cu.* device because they are different interfaces. They both go the same port, but they work differently.

So, when you get past that by just manually specifying the right tty on the commandline...

Brians-Air:pdd.sh bkw$ DEBUG=3 pdd /dev/cu.usbserial-AL03RAXP
/usr/local/bin/pdd: line 55: ${OSTYPE,,}: bad substitution
/usr/local/bin/pdd: line 143: typeset: -A: invalid option
typeset: usage: typeset [-afFirtx] [-p] name[=value] ...
/usr/local/bin/pdd: line 214: 3F: value too great for base (error token is "3F")
/usr/local/bin/pdd: line 217: typeset: -A: invalid option
typeset: usage: typeset [-afFirtx] [-p] name[=value] ...
/usr/local/bin/pdd: line 226: typeset: -A: invalid option
typeset: usage: typeset [-afFirtx] [-p] name[=value] ...
/usr/local/bin/pdd: line 236: typeset: -A: invalid option
typeset: usage: typeset [-afFirtx] [-p] name[=value] ...
/usr/local/bin/pdd: line 343: typeset: -A: invalid option
typeset: usage: typeset [-afFirtx] [-p] name[=value] ...
/usr/local/bin/pdd: line 385: -3: substring expression < 0
Using port "/dev/cu.usbserial-AL03RAXP"
open_com()
set_stty()
stty: illegal option -- -F
usage: stty [-a|-e|-g] [-f file] [options]
stty: illegal option -- -F
usage: stty [-a|-e|-g] [-f file] [options]
PDD(opr:24, )> 

dooblydoo... lotta stuff... well, the stty illegal option is only because the unrecognized ${OSTYPE,,} means it didn't select the macos version of stty syntax. And the unrecognized typeset option is annoying but simple to change. At least I think this version of bash supports associative arrays even if not the typeset -A option...

Initial googling failed to turn up an answer about installing macports or other packages without xcode, however it does show that you don't need to install xcode just the cli tools which is a much smaller download, and they give a simple single command to run to do it, but not something clickable in the app store.

I thought there was something that worked like freebsd pkg that could install binary packages.

@bkw777
Copy link
Owner

bkw777 commented Aug 26, 2022

Might have hit a show-stopper.
I held my nose and downgraded a few things to work in bash3 and the changes weren't too bad honestly, but now I just hit the problem that read -t # can't take a value less than 1 for timeout. It means read can't read for less than a full second timeout, which causes a couple problems, one, it will just make a lot of operations real slow, but the main problem is it's used as a replacement for /bin/sleep and needs to be able to sleep for anywhere from a few ms to a few hundred ms in many many places.

I'd rather tell the user to install bash4 or greater than to call /bin/sleep ;)
Maybe I won't mind making a whole separate alternate version of the file named "crappy_failure_pdd.sh" that has that in it. I'll have to think about this a while to try to figure out if there is any other way to polling and reading and stuff without being able to sleep for less than a whole second, or just have a fallback to use /bin/sleep if the bash is too old.

@bkw777
Copy link
Owner

bkw777 commented Aug 26, 2022

I put my current progress into a branch named bash3 so you can follow it if you want. It's not working yet but it starts up without error and gets further along. Currently it starts and the tty selection menu is correct, no stty error, several random syntax errors fixed that you never got far enough to see yet, and when I try to ls it just times out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant