]697;DoneSourcing proceeds plug-in output

craigz commented 2 years ago

Running SwiftBar 1.4.2 and notice in the menubar the text ]697;DoneSourcing next to the output of the running plugin. I've checked the plugin I'm running and see nothing in the script to suggest 'sourcing'.

For kicks i installed and enabled a random plugin and it too had the text proceeding the script output in the menubar.

I've deleted the application and reinstalled the latest with no change in behavior.

the plugin(s) run from a terminal session do not print that text, only the expected output for each script.
the plugin i'm running is in python, the one i enabled for testing was a shell script, so it doesn't seem to be something language related.
i've enabled Plugin debug mode and in the Plugin debug window see the text with each content update.
i'm running macOS 12.1 on a M1.

screenshots:

2 enabled plug-ins in menu:

content update in debug window:

melonamin commented 2 years ago

Hi @craigz,

Have you checked your zsh\bash profile? Maybe something there? As an option you can try adding this option <swiftbar.runInBash>false</swiftbar.runInBash> and see if anything changes.

craigz commented 2 years ago

where would i add the <swiftbar.runInBash>false</swiftbar.runInBash> option?

i've just inspected my .zshrc and see nothing new or out of the ordinary. i'm also running oh-my-zsh, but have been for some time as well and had not seen this issue until today.

melonamin commented 2 years ago

where would I add

as a comment in your python file, anywhere on top

i've just inspected my .zshrc and see nothing new or out of the ordinary.

interesting, this was my first guess... I don't see how SwiftBar would add such a string, so I looking for something on the outside.

craigz commented 2 years ago

I've added <swiftbar.runInBash>false</swiftbar.runInBash> to the comments at the beginning of the script and both refreshed the plugin from the debug window as well as quit & relaunched swiftbar, but the text remains proceeding the script output.

Interestingly when i print plugin metadata from the debug window, i see the similarly formatted options from the prefs (such as <swiftbar.hide.RunInTerminal>true</swiftbar.hide.RunInTerminal>) but i don't see the just added option in there.

I'm not sure what could be adding this goofy text string, and of course google is of very little help when searching bizarre ascii command codes.

I also messed a bit with the script's #! line and changed the interpreter from the system python to a different installed version. As that made no change, i then changed it to a non-existing path, just to see and in that case, the script failed (as expected) and the only text in the menubar was SwiftBar. As soon as i restored the shebang to a working python path, the same text re-appeared in front of the script output.

melonamin commented 2 years ago

can you share the plugin with me?

craigz commented 2 years ago

sure, i've created a gist. (edit: i guess you can't embed a gist in a comment. oh well, the link is below). script source

however, in testing i had grabbed an unseen before random plugin and it exhibited the same behavior, so i don't think it's anything in the plugin itself. i am currently running thru .zshrc & the omz configuration to see if there is anything with similar output. of course, i don't see that text when opening a new terminal or reloading zsh (init zsh).

melonamin commented 2 years ago

And in addition to that, can you try running the simplest possible plugin, like:

#!/bin/bash
echo "Test"

It would be easier to debug this way.

craigz commented 2 years ago

sure enough, that one also does it:

melonamin commented 2 years ago

So it's not python... try switching Shell

CleanShot 2022-01-26 at 12 54 22@2x

craigz commented 2 years ago

i've tried that and every time i change it from Bash to Zsh and quit then restart SwiftBar, it reverts to Bash ☠️

melonamin commented 2 years ago

Ok, this one is easy at least, just a dumb bug. Try this build SwiftBar.app.zip

craigz commented 2 years ago

indeed, that fixed the preference 'sticking' across reboots. so, i changed from Bash to Zsh quit & restarted SwiftBar, and confirmed both the ]697;DoneSourcing preamble exists as well as the shell configuration remaining Zsh in preferences.

melonamin commented 2 years ago

I don't have any fresh idea... any updates from your end?

omeraloni commented 2 years ago

@craigz Same thing exactly happened to me after installing Fig, what are the chances you're also using it?

Verified that the issue was resolved after uninstalling Fig.
Verified the same issue happens for any SwiftBar scripts I have.
SwiftBar script functions as it should, it's just a display issue (and likely some leaf from some broken pipe or something).

craigz commented 2 years ago

@melonamin i was going to reply that i'd too uncovered nothing new. however @omeraloni has hit the nail on the head, as i'm also running fig.

disabling fig did resolve the issue.
as does using the current xbar beta (v2.1.7-beta).

melonamin commented 2 years ago

@omeraloni thank you for saving the day! 💪

disabling fig did resolve the issue.

@craigz I'm happy to hear that!

as does using the current xbar beta (v2.1.7-beta).

...but this hurts! So I installed Fig and run some tests:

https://user-images.githubusercontent.com/222100/151640600-ce9c03da-0ee8-4500-a98e-adbeaba60ed3.mp4

As you can see:

Fig breaks only bash, at least in my fresh install of it
As soon as I switch to runInBash=false the problem goes away, which makes sense because it doesn't run any .bashrc/.zshrc/etc.

This is what Fig puts in .bashrc:


#### FIG ENV VARIABLES ####
# Please make sure this block is at the start of this file.
[ -s ~/.fig/shell/pre.sh ] && source ~/.fig/shell/pre.sh
#### END FIG ENV VARIABLES ####

#### FIG ENV VARIABLES ####
# Please make sure this block is at the end of this file.
[ -s ~/.fig/fig.sh ] && source ~/.fig/fig.sh
#### END FIG ENV VARIABLES ####

And sure enough if you search inside ~/.fig you'll convict the suspect:

I'm not curious enough to figure out what Fig is actually doing, and consider the case closed 🧐

craigz commented 2 years ago

Hi, I've noticed fig puts the same into ~.zshrc (perhaps not by default).

I tried running again with runInBash=false however had the same results as before.

I also tried runInZsh=false which also did nothing, but i had made up that option. Is there an equivalent run in zsh option? if so, is the syntax different than the option that i made up and tried? That seems to be the only difference at this point.

I would much rather run SwiftBar than the alternative, as it's faster and I like it better 😉

melonamin commented 2 years ago

Yeah, the name is weird, it is more like runInShell=false, meaning that runInBash doesn't care what shell you're using.

runInBash=false will execute something like this: plugin_path args runInBash=true will do this: [/bin/bash or /bin/zsh] -c -l "plugin_path args"

omeraloni commented 2 years ago

runInBash=false solved my issue. Opened Fig breaks bashrc and messes up SwiftBar display · Issue #854 · withfig/fig, I believe they'll fix it in no time. I'm also meeting one of their devs 1:1 next week so I'll raise this issue.

omeraloni commented 2 years ago

So apparently Fig taps into your shell and listens to any output. Debugged this issue with one of Fig's devs and he offered the following workaround (until they fix it):

Open ~/.fig/shell/post.bash
Add the following condition for the last statement (fig_osc "DoneSourcing"):
```
if [ -z $SWIFTBAR ]; then
fig_osc "DoneSourcing"
fi
```

craigz commented 2 years ago

I tried the same with ~/.fig/shell/post.zsh which has slightly different syntax than the post.bash file.

in that case, wrapping the "DoneSourcing" line causes the entire SwiftBar output to disappear from the menubar, while commenting out the conditional returns ]697;DoneSourcing... to the menubar.

also, i tried adding both: <swiftbar.runInShell>false</swiftbar.runInShell> and when that didn't change anything, for kicks i added both:

<swiftbar.runInShell>false</swiftbar.runInShell>
<swiftbar.runInBash>false</swiftbar.runInBash>

however, neither variant changed the behavior, with the below menubar:

melonamin commented 2 years ago

@omeraloni thanks for the insight!

Fig taps into your shell and listens to any output

This sounds... scary! ☠️

omeraloni commented 2 years ago

Correcting myself, Fig listens to anything you type in your terminal (still a bit scary though).

omeraloni commented 2 years ago

I tried the same with ~/.fig/shell/post.zsh which has slightly different syntax than the post.bash file.

in that case, wrapping the "DoneSourcing" line causes the entire SwiftBar output to disappear from the menubar, while commenting out the conditional returns ]697;DoneSourcing... to the menubar.

@craigz I've changed my SwiftBar shell to zsh and the same workaround worked for me.

Notice that even if you're using zsh as your main shell, SwiftBar has its own setting (default is bash), so maybe yours is still bash:

davidpurnell commented 2 years ago

I had the "]697;DoneSourcing" scourge as well. Changing shell to Zsh in the swiftbar prefs is what fixed it for me.

running Swiftbar 1.4.3 beta 2 & Fig 1.0.55 (B365)

lookfirst commented 2 years ago

So apparently Fig taps into your shell and listens to any output. Debugged this issue with one of Fig's devs and he offered the following workaround (until they fix it):

Open ~/.fig/shell/post.bash

Add the following condition for the last statement (fig_osc "DoneSourcing"):
if [ -z $SWIFTBAR ]; then
  fig_osc "DoneSourcing"
fi

This works great, but every time fig updates, it wipes out this change. Bummer.

swiftbar / SwiftBar

]697;DoneSourcing proceeds plug-in output #269