[00:12] <Ronin> Hii there, so im using crux
[00:12] <Ronin> anyway for me to install snap from source ?
[01:03] <Pharaoh_Atem> niemeyer: you there?
[01:03] <Pharaoh_Atem> Ronin: no
[01:03] <Pharaoh_Atem> Ronin: unless you're referring to snapd?
[01:04] <Ronin> Pharaoh_Atem: yee i was referring to snapd
[01:05] <Pharaoh_Atem> Ronin: crux would be difficult due to missing systemd
[01:06] <Ronin> i wouldnt call it missing , but thats unlucky i guess
[01:06] <Ronin> my search for a way to get discord continues lol
[01:07] <Pharaoh_Atem> Ronin: does CRUX provide flatpak?
[01:09] <Pharaoh_Atem> hmm guess not
[01:09] <Pharaoh_Atem> Ronin: Discord is available as a snap and a flatpak
[01:10] <Ronin> Pharaoh_Atem: yupp i know
[01:10] <Ronin> its the one package im missing
[01:10] <Pharaoh_Atem> heh
[01:10] <Pharaoh_Atem> it's the first time in a while I've heard of anyone using CRUX
[01:19] <Ronin> im using void linux on my main system
[01:19] <Ronin> installed crux on my laptop to try it out, gotta say i quite like it so far
[01:19] <Ronin> just that im missing some packages
[04:25] <mup> Bug #1781120 opened: 18.04 kernel 4.15.0-24 snappy can't start <Snappy:New> <https://launchpad.net/bugs/1781120>
[06:47] <zyga> good morning
[06:54] <pstolowski> mornings, hey zyga
[07:13] <zyga> cześć!
[08:01] <zyga> pedronis: hey
[08:01] <zyga> pedronis: around?
[08:10] <zyga> pstolowski: I'll move json serialization of various repo types to the daemon
[08:12] <pstolowski> zyga: makes sense
[08:12] <zyga> I think we agreed to do this long time ago
[08:12] <zyga> or something similar
[08:19] <zyga> wow
[08:20] <zyga> I found a file with copyright 2014
[08:22] <zyga> wow
[08:22] <zyga> we have copies of repo json code in daemon :)
[08:22]  * zyga is happy to clean this up
[08:27] <oSoMoN> can someone in the know confirm that when a snap is unpublished from the store, it doesn't get uninstalled from user's devices?
[08:28] <zyga> oSoMoN: that's correct
[08:28] <zyga> we don't have any code that could uninstall a snap
[08:28] <zyga> this way that is
[08:33] <oSoMoN> zyga, thanks
[08:47] <zyga> pstolowski: can you please look at https://github.com/snapcore/snapd/pull/5496
[08:47] <mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
[08:47] <pstolowski> zyga: sure
[08:48] <mup> PR snapd#5496 opened: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
[08:48] <zyga> I'll keep hacking in that direction, there is clearly some more cruft there
[08:49] <zyga> Chipaca: hey
[08:49] <zyga> around?
[08:50] <Chipaca> zyga: no
[08:50] <zyga> :D
[08:50] <Chipaca> zyga: asquare
[08:51] <zyga> perfect
[08:51] <zyga> daemon api question
[08:51] <zyga> how would you feel if I moved all the jsonization types to api_json.go
[08:51] <zyga> I added some there because I'm cleaning up the interface repository json story
[08:51] <zyga> and I noticed we have a few types scattered around the api.go file
[08:51] <Chipaca> zyga: including the stuff in snap.go?
[08:52] <zyga> while you think please look at 5496 api_json.go to see what that would look like
[08:52] <zyga> no, only stuff unique to the api layer
[08:52] <zyga> that is currently in random places in api.go
[08:52] <Chipaca> zyga: daemon/snap.go
[08:52] <zyga> ah, this one
[08:52] <zyga> no, I don't think so
[08:53] <Chipaca> zyga: it's the only snap.go :-)
[08:53] <zyga> nothing there uses json tags
[08:53] <zyga> I though of snap/*.go
[08:53] <Chipaca> zyga: correct, code there just builds map[string]stuff
[08:53] <zyga> that is fine
[08:53] <zyga> I just noticed we have some duplication in the types
[08:54] <zyga> because they were in separate packages
[08:54] <zyga> and also some types were super-alike
[08:54] <zyga> and just defined few pages away from each other
[08:54] <Chipaca> zyga: if it's duplication between daemon and client, that was intentional
[08:54] <zyga> no no
[08:54] <Chipaca> (which isn't to say i agree with it)
[08:55] <zyga> this is all in the daemon/* area
[08:55] <zyga> I know about the purpuseful duplication with the client package
[08:55] <Chipaca> k
[08:57] <Chipaca> zyga: I'm not sure I understand 5496
[08:57] <Chipaca> zyga: in general I think it's better to have the marshaller next to the type it's  marhsalling
[08:57] <zyga> yes, but:
[08:58] <Chipaca> zyga: were the slotJSON etc in daemon even used?
[08:58] <zyga> 1) we never intended to return snap.{Plug,Slot}Info this way
[08:58] <zyga> 2) we had duplicates between repo and daemon
[08:58] <zyga> (yes, both were used /o\)
[08:59] <zyga> 3) we want to introduce code that changes some of the info's just before they are sent and pedronis opposed doing that to the original types
[08:59] <zyga> so I want to do that to the json types instead
[08:59] <zyga> hence the clenaup
[08:59] <zyga> *cleanup
[08:59] <zyga> both types were used because we have legacy/non-legacy interface APIs
[08:59] <Chipaca> fair
[08:59] <zyga> and they used both by accident
[08:59] <zyga> a bit silly
[09:03] <pedronis> zyga: seems my worry is introducing lots of complications, otoh that remapping by taking an info and just changing name inside looks very strange/fragile at face value
[09:03] <zyga> pedronis: not complications, cleanups
[09:04] <zyga> pedronis: there were clearly copy/pasted types around
[09:04] <zyga> pedronis: not that I didn't change the info that was handed in, I returned a modified copy
[09:04] <Chipaca> some day I'll have time to rewrite daemon
[09:04] <pedronis> I know
[09:04] <Chipaca> there's so much stuff i'd do better today
[09:04] <pedronis> still strange
[09:05] <pedronis> I'm also not sure did those infos had implicit slots in them, does it matter ?
[09:06] <zyga> pedronis: they had slots, both implicit and not
[09:07] <zyga> pedronis: they were added at a much earlier stage
[09:07] <zyga> in the request/response timeline, not in our git log  timeline)
[09:07] <pedronis> so were basically taking a snapd  snap info (with implicit slots) and calling it core ?  or the other way around
[09:07] <pedronis> that's admittedly strange
[09:07] <zyga> yes
[09:08] <zyga> in reality it was just a way to return a snap name and slot name
[09:09] <pstolowski> zyga: thanks for that cleanup.. i remember cleaning some of that (the legacy connections) but missed the second part
[09:10] <zyga> pstolowski: I pushed the second patch to the PR so that there is no duplication inside the daemon either now
[09:12] <zyga> ok, with this the re-mapping code should no longer have to touch snap.Info
[09:23]  * zyga cannot wait for tests to finish
[09:42]  * Chipaca afk for a while
[10:42] <zyga> pstolowski, pedronis: https://github.com/snapcore/snapd/pull/5496 is green and blocking me
[10:42] <mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
[10:42] <zyga> can we land it
[10:45] <mup> PR core18#44 closed: hooks: fix 030-fix-timedatectl.chroot to DTRT when running on non-core devices <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/44>
[10:49] <zyga> guys?
[10:50] <zyga> jdstrand: hey, around?
[11:04] <pstolowski> zyga: i need to give it proper looked, only skimmed through it; will review before/after standup
[11:04] <pstolowski> *look
[11:05] <zyga> thanks
[11:05] <pstolowski> zyga: sorry about that
[11:09] <mup> PR snapd#5497 opened: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497>
[11:12] <zyga> pedronis: hmm is this expected:
[11:12] <zyga> https://www.irccloud.com/pastebin/8R1R97lR/
[11:12] <zyga> pedronis: I cannot abort change 54
[11:13] <Son_Goku> kyrofa, when snapcraft can finally build Fedora based snaps, it should forbid excluding `/usr/share/licenses`: https://forum.snapcraft.io/t/legal-issues-when-excluding-usr-share-doc/6341
[11:13] <pedronis> zyga: no idea
[11:13] <zyga> ah, it timed out now
[11:13] <pedronis> it has an undo
[11:13] <pedronis> but systemctl as well
[11:13] <Son_Goku> niemeyer: hey, you there?
[11:40]  * zyga iterates on the signal test
[11:43] <zyga> Chipaca: around?
[11:43] <zyga> Chipaca: can you please review https://github.com/snapcore/snapd/pull/5496
[11:44] <mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
[11:44] <Chipaca> zyga: knee deep in spread tests
[11:44] <zyga> ack
[11:44] <zyga> next step: waist deep? :)
[11:51] <Chipaca> zyga: I daren't venture more into the miasma, as it sucks you in
[11:51] <Chipaca> also, I daren't postpone lunch
[11:51]  * Chipaca goes to sort that out
[12:00]  * zyga prepares for lunch
[12:11] <zyga> eh eh eh
[12:11] <zyga> Chipaca: would it make sense to have a way to install a snap without starting the services
[12:12] <zyga> because the services require connection to an interface
[12:12] <zyga> that is not denied but also not auto-connected
[12:12] <zyga> Chipaca: the particular use-case is daemon-notify
[12:12] <zyga> it is a bit silly but it is not auto-connected
[12:13] <zyga> and this prevents daemon: notify services
[12:13] <zyga> this prevents the snap from being installed
[12:13] <zyga> catch 22
[12:13] <zyga> in effect nobody can develop a daemon: notify service ever
[12:14] <zyga> jdstrand: ^ FYI daemon: notify requires connected daemon-notify plug (not auto-connected) but this can never be done because failing services prevent the snap from being installed
[12:16] <zyga> jdstrand: I'm not sure if a snap-declaration assertion can override this (auto-connection of a slot that can be connected manually) but this is not useful for developers as far as experience is concerned
[12:16] <zyga> I think something has to go
[12:23] <pedronis> zyga: yes, snap-declaration can set auto-connect per snap
[12:24] <zyga> pedronis: thanks
[12:31] <jdstrand> zyga: it isn't silly that it isn't auto-connected. there have been vulnerabities on the notify socket. there is a card (still) to investigate that further, but the decision was to manually connect for now.
[12:32] <jdstrand> zyga: this sounds like a problem with the application. why is it crashing so hard?
[12:34] <Chipaca> jdstrand: systemd kills a notify daemon if  it doesn't notify within a timeout
[12:34] <jdstrand> I see
[12:34] <jdstrand> well, yes, auto-connection is available for now
[12:35] <Chipaca> but I thought you could just use snapctl to disable the service from the instlal hook
[12:37] <zyga> jdstrand: it is not crashing, it is not starting according to systemd as Chipaca explained
[12:38] <zyga> hmm, I wonder what to do, this is really about me fixing a flaky test
[12:38] <zyga> jdstrand: so it _should_ auto connect in when installed locally with --dangerous?
[12:39]  * zyga removed it for now, trying to see if this helps
[12:40] <zyga> it's quite annoying trying to develop a snap that keeps failing to install :)
[12:40] <zyga> I should break
[12:40] <zyga> see you at the startup
[12:42] <newbee> hi guys,  I have a java web application, now i want to create a snap for this app. when I tried to create a snap it shows "[Redirection detected from https to http. Protocol switch unsafe, not allowed.]" in the build part. please someone guide me to solve this problem.
[12:43] <zyga> newbee: not a snapcraft expert but this seems like the URL was specified as HTTPS but something (perhaps a proxy) redirected that to a HTTP, thus nullifying the encryption of the connection.
[12:43] <zyga> what is the URL you are hitting?
[12:46] <newbee> @zyga, I am not using any URL for this, in my snap I call tomcat in the part. In the building part it shows this error.
[12:48] <newbee> @zyga : the snap access the URL in the build.xml file to buils the tomcat
[12:50] <newbee> @zyga :Can you please give me some examples to create the tomcat snap.
[12:50] <zyga> no
[12:50] <zyga> I don't know anything about tomcat
[12:50] <zyga> let me look if we have any stock examples though
[12:51] <newbee> Okay thank you...
[12:51] <zyga> newbee: looking at https://wiki.ubuntu.com/snapcraft/parts I see some tomcat parts, maybe that will be of some help
[12:52] <newbee> Is there any other way to create the web snap in ubuntu core?
[12:55] <Chipaca> newbee: I think you'd be best starting a topic on the forum
[12:59] <zyga> newbee: I think you can create a web-talking snap using the typical suspects: python, java, go; it's just that I'm not the best person to share examples with you as I work on the other side of snappy (the service)
[12:59] <zyga> newbee: perhaps kyrofa or popey have some tomcat-based snaps they can point you to
[13:00] <zyga> newbee: though Chipaca's advice stands: this is a perfect topic for the forum where people will see it outside of the 15minute focus window of your question here
[13:03] <newbee> @zyga : Thanks for your help... I will start this topic on the forum...
[13:04] <Chipaca> hmm, standup
[13:05] <newbee> @Chipaca : Okay....
[13:14] <popey> zyga: i have no tomcat snaps
[13:44] <zyga> jdstrand: hey, about sd-notify, did we consider having snapd be the proxy for the socket
[13:44] <zyga> jdstrand: so it could read the requests, inspect them and forward/ignore
[13:45] <zyga> jdstrand: is this something that is doable or is systemd going to ignore the messages relayed by another process?
[13:46] <jdstrand> zyga: we didn't afaik. I suspect that systemd would then monitor snapd in that case
[13:46] <zyga> mmm, interesting,
[13:46] <zyga> if this is something that would need systemd patches then we cannot rely on it
[13:46] <zyga> so no notification by default, no proxying possible,
[13:47] <zyga> jdstrand: although systemd-notify has a --pid argument so _perhaps_ we could
[13:48] <jdstrand> zyga: as mentioned, this isn't a feature I'm super familiar with. there is a card to investigate further to see if we can make it auto-connect. that card continues to have several things in front of it
[13:49] <zyga> jdstrand: sure, no worries, this is not a priority bump of any kind
[13:50] <pedronis> zyga: I triple-checked,  with --dangerous auto-connect are based on the base declaration, so you get the things that are allowed there
[13:50] <zyga> pedronis: thank you!
[13:50] <zyga> pedronis: this makes sense now
[13:50] <jdstrand> zyga: I can say that if snapd could somehow proxy it, it could probably be made auto-connectable (just need to make sure that a snap couldn't interfere with other snaps via the proxy
[13:50] <zyga> pedronis: because base declaration connections vs no connections at all makes the difference
[13:50] <zyga> jdstrand: right
[13:50] <zyga> thank you both
[13:51] <pedronis> zyga: notice that if we made  non-installable vs not auto-connectable, it would also solve the issue
[13:51] <pedronis> given that it seems installing doesn't work anyway
[13:51] <zyga> hmm, what do you mean by non-installable?
[13:52] <pedronis> say you annot install a snap with interface, unless the snap-declaration says so
[13:52] <zyga> ah, right
[13:52] <zyga> yes
[13:52] <zyga> though I'm not sure if we would dump the plug/slot and carry on as today or refuse outright
[13:52] <pedronis> ?
[13:53] <pedronis> it refuses outright
[14:06] <zyga> re
[14:34] <jdstrand> zyga: that said, writing up a proxy just because an analysis isn't done isn't great. someone could write up an in depth analysis and provide it to me, justifying auto-connecction (ie, that the code is safe from root attacks and the mechanism can't be used to influence other snaps)
[14:35]  * jdstrand -> errand
[14:45] <zyga> jdstrand: I won't write the proxy anytime soon, though the analysis seems like more complex (given the extent of systemd and the numerous versions we'd have to inspect)
[14:45] <zyga> Chipaca, pstolowski: gentle ping about https://github.com/snapcore/snapd/pull/5496
[14:45] <mup> PR #5496: interfaces,daemon: move JSON types to the daemon <Created by zyga> <https://github.com/snapcore/snapd/pull/5496>
[14:45] <Chipaca> zyga: reviewing is happening as we speak
[14:46] <Chipaca> zyga: or rather, it would be, but instead we're speaking
[14:46] <pstolowski> zyga: you got my +1 an hour ago
[14:50] <zyga> oh
[14:50] <zyga> drat, github stale page :)
[14:51] <Chipaca> zyga: what happened to the tests
[14:51] <zyga> I would love to use github on a text mode interface with mouse clicks support if it at least reliably worked
[14:51] <zyga> Chipaca: the tests for MarshalJSON, gone with the method, this is already tested by the api tests
[14:52] <zyga> specifically for the code that runs getInterfaces or getLegacyConnections (AFAIR, the typing names from memory)
[14:52] <zyga> the single call was inlined and that is tested as before, note that this patch didn't change any outcomes anywhere
[14:52] <zyga> just removed redundancy
[15:04] <zyga> Chipaca: thank you :)
[15:04] <mup> PR snapd#5496 closed: interfaces,daemon: move JSON types to the daemon <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5496>
[15:04] <Chipaca> zyga: that's not a thumbs up, that's a "if the nuclear explosion is bigger than my thumb i need to evacuate"
[15:04] <zyga> haha :)
[15:04] <zyga> aka the "nuclear painter's algoritm"
[15:04] <zyga> algoritm
[15:04] <zyga> man
[15:04] <zyga> algorithm
[15:06] <Chipaca> zyga: al juarismi
[15:06] <Chipaca> zyga: so we can get into a gif vs jif fight about that as well
[15:06] <zyga> giajef?
[15:07] <zyga> poles often enumerate the letters in abbreviations
[15:07] <zyga> so things are more like G-I-F than jif or gif
[15:07] <Chipaca> zyga: it depends on whether you can read it or not i guess; Spanish does that for jpg but not for gif
[15:08] <zyga> heta-i-efa
[15:08] <zyga> or something
[15:08] <zyga> efe
[15:08]  * zyga needs to run an errand
[15:08] <Chipaca> zyga: is it very obvious that we're waiting for spread here
[15:09]  * Chipaca looks into tea
[15:18] <Chipaca> zyga: niemeyer: what we should do i snapd is not try to start a service if it's type:notify and it's not connected
[15:18] <Chipaca> that's enough
[15:18] <Chipaca> in a world with warnings, we'd issue a warning at the same time
[15:21] <ogra_> Chipaca, found anything interesting in your tea ?
[15:21] <Chipaca> ogra_: enlightenment
[15:21] <ogra_> !
[15:22] <Chipaca> ogra_: a very narrow enlightenment, but still
[15:28] <mup> PR snapd#5490 closed: store: make snap blobs be 0600 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5490>
[15:44] <pstolowski> niemeyer, zyga good news, the libudev internal data header for udev events is the same in 14.04 and 18.04
[15:46]  * zyga is in Łukta now
[15:49] <Chipaca> zyga: is that pronounced "wukta"?
[15:57] <pstolowski> Chipaca: wookta
[15:58] <Chipaca> pstolowski: tks
[17:13] <mup> PR snapcraft#2178 closed: lifecycle: pass commands to containerbuild, not steps <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2178>
[17:39] <smoser> hi. if i try to register a name (pdftk) and it is coming up as "reserved". does that mean it has been reserved by someone else ? or possibly just that it is reserved due to there being a package name ?
[17:43] <smoser> or per https://forum.snapcraft.io/t/pending-review-on-flock-reserved-name/5442 maybe all binaries in ubuntu got reserved names automatically ?
[18:09] <kyrofa> smoser, indeed, just submit a claim for it
[19:21]  * zyga returns for some evening hacking :)
[19:21] <zyga> hey kyrofa
[19:21] <zyga> how have you been?
[20:54] <kyrofa> Hey zyga, not bad, how about you?
[20:57] <jdstrand> matiasb_: hi! with the full epoch syntax, is this true: read and write must be lists of positive integers, with no transition specified (ie, no '*') and '0' not allowed?
[20:58] <jdstrand> matiasb_: ie, this is ok epoch: {'read': [1, 2]}
[20:58] <jdstrand> matiasb_: but this is not: epoch: {'write': [0, 1]}
[20:58] <jdstrand> matiasb_: and neither is this: epoch: {'write': [1, 2*]}
[20:59] <jdstrand> matiasb_: from the examples, it seems clear [1, 2*] is not allowed, but nowhere does it say n>0, so not sure about [0, 1]
[21:00] <jdstrand> matiasb_: (n>0 is only specified with the simple syntax)
[21:00] <matiasb_> jdstrand, o/ right, I think 0 is allowed in the lists; the only case where 0 is not allowed is when using the * syntax, which is not allowed inside a list
[21:01] <jdstrand> ah, 0 is ok, just not with *
[21:01] <jdstrand> gotcha
[21:01] <matiasb_> exactly
[21:01] <jdstrand> matiasb_: thanks!
[21:01] <matiasb_> np!
[22:19] <mup> PR snapd#5498 opened: snap: support hook environment <Created by kyrofa> <https://github.com/snapcore/snapd/pull/5498>
[23:02] <kyrofa> niemeyer, that's ^ for you
[23:02] <niemeyer> <3
[23:02] <niemeyer> kyrofa: Thanks!
[23:20] <kyrofa> niemeyer, I just learned that the `command` of an app doesn't take the PATH in the `environment` key into account. Is that on purpose, or a bug?
[23:21] <kyrofa> It always just appends it to the snap mountdir
[23:23] <niemeyer> kyrofa: Yeah, it's on purpose.. what would be the use case for looking at an arbitrary path?
[23:24] <kyrofa> niemeyer, for binaries in bin, for example
[23:24] <kyrofa> Snapcraft supports this by placing wrappers in the root with the PATH defined, if snapd doesn't support it migration will be somewhat rough
[23:24] <niemeyer> kyrofa: Sure, but what's the use case for not defining that explicitly?
[23:26] <kyrofa> A nicety, I suppose. You can put a dir in the PATH and then not have to include the entire path in the command
[23:26] <kyrofa> The real issue is that people are doing it today, so getting rid of wrappers either means rewriting folks `command`, or adding support to snapd to check the PATH
[23:27] <niemeyer> kyrofa: They need to touch the command either way
[23:27] <niemeyer> Right?
[23:27] <niemeyer> Sorry, perhaps not the command.. the yaml I mean
[23:27] <niemeyer> Since we need to support the current files untouched
[23:28] <kyrofa> No, snapcraft does. Today it generates the wrapper and rewrites the command. Tomorrow it (ideally) stops generating the wrapper and only touches the `environment` of the command. But that can't happen if the command isn't found
[23:28] <kyrofa> The user should notice no difference
[23:28] <kyrofa> Again, ideally
[23:29] <niemeyer> kyrofa: Yeah.. it's a bit of a bummer..
[23:30] <kyrofa> Snapcraft can rewrite the app to be absolute, but that kinda sucks
[23:30] <kyrofa> Err, relative to the root of the snap I mean
[23:30] <niemeyer> kyrofa: I guess snapcraft could resolve the PATH itself in those cases
[23:30] <kyrofa> Indeed
[23:30] <kyrofa> Still probably better than a wrapper, but I was hoping we wouldn't have to touch what the user provided anymore
[23:30] <niemeyer> kyrofa: and then ideally stop doing it when we detect a new format yaml
[23:30] <niemeyer> (with base, etc)
[23:31] <kyrofa> niemeyer, it also means that command chain items need paths to them. That doesn't seem overly verbose?
[23:32] <niemeyer> kyrofa: No, seems okay.. the PATH in general is something the user sets up for their environment.. for a snap, we are explicitly defining what the command means.. it shouldn't change if things fiddle with the path
[23:33] <kyrofa> Okay. Caught me by surprise, it may catch others
[23:33] <niemeyer> kyrofa: I'm surprised in the opposite direction :D
[23:33] <kyrofa> Heh
[23:34] <kyrofa> Snapcraft can help with the messaging
[23:58] <kyrofa> Hmm... that still won't solve all the cases though, e.g. where people actually use shell commands as a command
[23:59] <kyrofa> `command: echo "hello"` works today. It can never work in that world