TAB character (\t or \x09) to separate args in script filter??

[luckman212]

Pulling my hair out on this one.

I have a script filter which generates args in the format

arg1(tab)arg2(tab)arg3 with spaces

Where (tab) is a literal tab character (HEX 0x09) aka \t in regex.

No matter what I've tried, Alfred always mangles the tabs into spaces (HEX 0x20) which is no good for me since Arg3 may contain spaces and needs to be processed by the bash script as a single parameter.

 

If, instead of a Script Filter, I use a standard List Filter and press the [tab] key in the Arg field, something like this

...that passes the Tabs on to the bash script correctly.

 

Anyone know why this is happening or is there any workaround? Is this a bug?

Edited April 28, 2019 by luckman212

[deanishe]

1 hour ago, luckman212 said:

Alfred always mangles the tabs into spaces

 

It doesn't for me…

 

Can you upload your non-working workflow somewhere and post a link to it, so we can have a look? I'm not seeing any problems with Alfred's behaviour.

[luckman212]

Thanks @deanishe for taking time to reply.

Here's a sample workflow that shows the issue I'm facing called BrokenTabs
https://nas.ldh.me/ss/BrokenTabs.alfredworkflow.zip

It has 2 keyword triggers:  btabsf (script filter) and btablf (list filter)

The List Filter works fine, but the script filter doesn't.

Hope you will be able to see what I mean after playing with it.

 

[deanishe]

Yeah, there seems to be an issue with the XML parser. I couldn't reproduce the problem because I was using JSON. So, the solution is to use JSON, not XML, which is deprecated in any case. This works as expected:

cat <<'EOF'
{"items": [
    {"title": "FooBar Device", "arg": "connect\t00-11-22-33-44-55\tFooBar Device"},
    {"title": "FooBar Device", "arg": "connect\taa-bb-cc-dd-ee-ff\tBooBaz"},
    {"title": "FooBar Device", "arg": "connect\tff-ff-ff-ff-ff-ff\tNull Thingy"}
]}
EOF

If you don't actually need the List Filter and just want to use a Script Filter, a better way to do it, imo, is using workflow variables:

cat <<'EOF'
{"items": [
    {"title": "FooBar Device", "variables": {"cmd": "connect", "mac": "00-11-22-33-44-55", "name": "FooBar Device"}},
    {"title": "FooBar Device", "variables": {"cmd": "connect", "mac": "aa-bb-cc-dd-ee-ff", "name": "BooBaz"}},
    {"title": "FooBar Device", "variables": {"cmd": "connect", "mac": "ff-ff-ff-ff-ff-ff", "name": "Null Thingy"}}
]}
EOF

That way you don't have to mess around parsing any input or worry about spaces in the values. You can just directly use $cmd, $mac and $name in your bash script.

 

See here for more info on workflow variables.

Edited April 29, 2019 by deanishe

[luckman212]

@deanishe Hmm, interesting! I knew XML was considered "legacy" but didn't know it was deprecated completely. I want to switch to JSON but my Python is super rusty and I was struggling to generate clean, valid JSON with pure Bash scripting. Any tips for generating JSON from e.g. CSV or tabular data?

 

For now, I came up with a poor man's workaround- using semicolon `;` as a delimiter instead. I'm not happy about it, but I guess this will probably not be fixed in Alfred so I will try to look at switching to JSON. I see that XML mode also supports using variables in the script filter so I may give that a try as well. Thanks for the help 🙂

[vitor]

10 minutes ago, luckman212 said:

I was struggling to generate clean, valid JSON with pure Bash scripting. Any tips for generating JSON from e.g. CSV or tabular data?

 

I’m a huge Bash user and frequently grab it as the first (and fastest) tool for a job, but even I will tell you that if at any point it involves JSON, I’ll switch to something else (Ruby).

That said, jq is a popular tool that might help you. Someone also made a pure bash script to do just what you ask. I’ve never tried either, so I can’t vouch for their effectiveness (or warn against bugs).

Edited April 29, 2019 by vitor

[deanishe]

1 hour ago, luckman212 said:

Any tips for generating JSON from e.g. CSV or tabular data?

 

Use a language that has proper support for JSON and CSV would be my advice. Same goes for XML, tbh.

 

It's easy enough to cobble together your own JSON/CSV/XML until it suddenly isn't anymore because one of the values contains something that needs escaping. Better to use a real library and never worry about it again.