Allow Backslash Escaping of Pipes

[boppy]

This little change would allow to use pipes in your output. My usecase was to be able to print figlet output inside argos.

It simply checks if there is a backslash in front of the pipe. So it might confuse properly escaped backslashes (like echo "This is a backslash \\|bash=\"sleep 10\"", but it will not confuse if spaces are used around the pipe (echo "This is a backslash \\ | bash=\"sleep 10\"") as in every example...

PS: I hope it's okay to not have opened an issue beforehand.

[boppy]

Just to complete - Used syntax:

#!/usr/bin/env bash

fig="$(figlet -f boppybox "keep calm...")"
fig="$(awk 1 ORS="\\\\n" <<< $fig)"
fig="${fig//|/\\|}"
echo "$fig | font='Source Code Pro' size=14"

[p-e-w]

I like the overall idea here. Spacing and indentation don't match the rest of the code, please fix that.

[p-e-w]

This fails if separatorIndex is zero and lineString ends with \.

Also, please use double quotes like the rest of the code.

[boppy]

Will fix that mistake and code style not later than this weekend.

[p-e-w]

I just realized there is a much cleaner solution that also covers all corner cases: Just replace indexOf in this line with a regular expression search using negative lookbehind, and you're done (it will have to be a GLib regex because JavaScript doesn't support lookbehind).

[boppy]

Absolutely. Unluckily there are not all C functions available in the JS frontend, so I have not been able to use g_regex_split_full with max_tokens, but instead splited and rejoined.

[p-e-w]

split_full is available, it's just not a static function. You first need to create a Regex object with regex_new, then you should be able to call split_full on it.

[boppy]

Sorry, but I need some more input. Using

log('its ' + typeof GLib.regex_new);

gives

its undefined

[p-e-w]

My mistake, seems like it's GLib.Regex.new. For the documentation to be any less clear it would have to be written in hieroglyphs... 😞

[p-e-w]

Hmm, it works for me:

1. Open Looking Glass
2. Type a = GLib.Regex.new("a", 0, 0), press Enter
3. Type a.split_full(), press Enter
4. "Error: Too few arguments to method GLib.Regex.split_full: expected 4, got 0"

[boppy]

You are absolutely right. Because the documention is that great, they use lazy loading for the functions, so nobody can ever find anything helpful in debugging...

I - again - feel like a total noob to programming... even with all your hints I'm far away of getting it to work...

I tried:

    try {
        var z = GLib.Regex.new("(?<!\\\\)\\|", 0, 0);
        var ls = lineString;
        // also tried:
        //var ls = lineString.split('');
        //var ls = GLib.locale_to_utf8(lineString);
        var o = z.split_full(ls, 0, 0, 2);
        log('xxx1', o);
    } catch(e){
        log('xxx2', e.message);
        log('xxx2', lineString);
    }

This always gives Cannot convert string to array of 'utf8' even for lines like --- or OTP. After manual split, empty Strings work, afer locale-convert the converted String is empty... For sure all my shell files are UTF8 encoded - In fact "OTP" or "---" do not differ much in any encoding out there...

Do you have any "better" source for GLib/Gnome/JavaScript? I am not able to find anything resilient...

Log extract:

Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, ---
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, sshfs
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, --<span color='#73D216'>5/5 present</span>
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, <span color='#73D216' weight='bold'>ssh</span>
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, --<span color='#73D216' weight='bold'>B4S3</span> | bash="ssh B4S3; exit"
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, --<span color='#73D216' weight='bold'>E1337</span> | bash="ssh E1337; exit"
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, --<span color='#faff00'>HH_live</span> | bash="ssh HH_live; exit"
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, --<span color='#73D216' weight='bold'>KRUU</span> | bash="ssh KRUU; exit"
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Cannot convert string to array of 'utf8'
Dec 02 16:59:34 <host> gnome-shell[2463]: xxx2, Krimskrams

[p-e-w]

Not sure what the particular problem is here, but I very much know this feeling of being stuck. Argos has less than 1000 lines of code in total, but some of those lines took many hours to write. As you mention, some things are just flat out undocumented, and the Gjs bindings also have bugs (including memory bugs; I managed many times to crash GNOME Shell from JavaScript).

To create Argos, I used a combination of Valadoc, whatever outdated/incomplete Gjs documentation was available at that time, and the GNOME Shell source code. I tried to learn from other Shell extensions, but quickly found the overwhelming majority of them to be riddled with errors and just have abysmal code quality in general. At the end of the day, very little existing code was of any help at all, and most of the progress came from trial-and-error in Looking Glass.

So I'm afraid there is no silver bullet here, and lots of things that are ultimately beyond your control. If you can't work this out, no worries. I don't consider this feature to be that important and I believe BitBar doesn't have it either. It is up to you if you want to pursue this further. But I must be clear that I won't be merging any hacks, or any code whose behavior we don't completely understand.

[catb0t]

you could possibly distill the problem into a minimal example and ask on https://unix.stackexchange.com / https://stackoverflow.com

[boppy]

But I must be clear that I won't be merging any hacks, or any code whose behavior we don't completely understand.

So the question of the day is: Do you feel that my split-shift-join is hacky (I skip the "not understanding" part because I'm in doubt that you are not understanding this... ^^)? I think it's okay since it is (to my believe) the only way to do a limited split with vanilla js (since the limiter on vanilla-.split is not working as in python or php, where splitting never "shortens" the input). It's okay for me that GLib tries to provide a better way of splitting, but since it's not working as expected, I think going back to the roots (=vanilla) is the best way possible.

I also feel that skipping the else case while parsing the line is enhancing the readability of the code.

@catb0t Good idea, but since there seem not to be that many gnome-js devs out there (otherwise "we" might already have partnered to give the gnome-js-dev team a litte visit ;)), I am not sure to gain any profit. Nevertheless I will compile a question and ask over there.

[boppy]

I fixed the issue and implented your RegEx idea. As a total gnome-ext noob I was not aware that there is an additional (better) RegEx implementation available.