20:00:03 <nitzmahone> #startmeeting Windows Working Group
20:00:03 <zodbot> Meeting started Tue Nov  7 20:00:03 2017 UTC.  The chair is nitzmahone. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:03 <zodbot> The meeting name has been set to 'windows_working_group'
20:00:54 <jborean93> Hi
20:01:48 <nitzmahone> #chair jborean93
20:01:48 <zodbot> Current chairs: jborean93 nitzmahone
20:02:34 <dag> o/
20:02:59 <dag> do we have any topics today ?
20:03:18 <jborean93> I think Jon may have had one
20:03:21 * jborean93 checks
20:04:02 <jborean93> yep there is https://github.com/ansible/community/issues/195#issuecomment-341626723
20:04:30 <dag> right, I think it's a valid request, it's a common type
20:04:33 <dag> not just for Windows though
20:05:25 <nitzmahone> Is @jhawkesworth_ about?
20:05:28 <dag> and this new type could accept both a list of command+options, but also a string
20:05:38 <jborean93> I am fine with having that, something like `-type expand_string` to match the registry definition
20:06:23 <dag> jborean93: I am less in favor of that, although I understand it's close to what Windows does
20:06:39 <jborean93> dag: what would you call it?
20:08:28 <dag> jborean93: I was thinking of something more like 'cmdline' or  'command'
20:08:40 <dag> and make it much more specific in use (may not cover other use-casesp
20:08:55 <jborean93> But that's not what the type really is, anything can use a string expansion and not just command line
20:09:32 <dag> true, but cmdline would allow for other testing as well
20:09:46 <jborean93> What other things would we validate against a cmdline type?
20:10:19 <dag> type 'path' was never intended for executable+params
20:10:45 <jborean93> My concern would be we add a cmdline type which expands a string only then want another type which does the same thing
20:10:48 <dag> we could test if the first argument is found, it could handle both single string, or a list
20:11:00 <dag> and this would be comparable on Windows and Linux
20:11:15 <nitzmahone> How generally applicable is that outside of shell/command though?
20:11:29 <jborean93> win_service is what brought it up
20:11:35 <nitzmahone> Ah, I see that now
20:11:46 <dag> if you make it expand_string, it becomes debatable what is expanded, and we wouldn't know what the value describes
20:11:48 <jborean93> I used `path` for the executable when people wanted to quote the path causing the validation to fail
20:12:23 <dag> psexec also has a cmdline, and there are a few others IIRC
20:12:33 <dag> also on Unix
20:12:44 <nitzmahone> (though the rules are different)
20:12:47 <dag> jborean93: is there a need to quote a path ?
20:12:54 <jborean93> In there case yes
20:12:58 <nitzmahone> C:\Program Files\blah.exe
20:13:02 <jborean93> s/there/their/
20:13:23 <jborean93> It's also a security concern, Windows will first try to find `C:\Program.exe` and execute that if it exists
20:13:33 <dag> jborean93: right, that would be solved by defining it as a list, or parsing the string
20:14:18 <dag> the type cmdline would require quotes or escape the space
20:14:26 <dag> I don't see how expand_string would solve that issue
20:14:34 <jborean93> We have code right now to parse a list to a string but unfortunately cross module_utils cannot set a dependency
20:14:49 <jborean93> Well they need to put the quotes or how else would we know what to do
20:14:53 <jborean93> If they didn't have a list
20:15:02 <nitzmahone> Well, and embedding quotes in YAML can be nightmarish, especially if Jinja2 gets involved
20:15:53 <nitzmahone> Cross module_utils deps can be done, we just didn't have a usecase for it when I built it, so I skipped the recursion
20:16:26 <dag> jborean93: indeed, so that's when a type 'cmdline' would be perfect, it clearly indicates what it is and what you can do with it
20:17:01 <dag> maybe if there's another use-case for expand_string, we can look if it makes sense then, but for command-lines I prefer to know what it is
20:17:02 <jborean93> If you have a list I agree it would help with the quoting, but if you pass a string we still wouldn't know to quote `C:\Program Files\blah.exe`
20:17:36 <nitzmahone> (nor do we want to "guess" ever)
20:17:44 <dag> nope, they'd have to quote
20:17:48 <dag> I agree
20:18:00 <nitzmahone> Path/cmdline parsing is hellish, esp if we're trying to reimplement/match existing behavior somewhere
20:18:03 <dag> for type path that's not needed because it's a single object
20:18:10 <nitzmahone> right
20:18:31 <dag> I agree that the difference between types path and cmdline would be confusing, but I don't see a real solution here
20:18:52 <dag> I would point to Microsoft for making spaces prevalent, but Unix has it too, so...
20:19:19 <dag> so the problem exist in both worlds, and type cmdline at least would help
20:19:33 <jborean93> If we get recursive module_util dependencies it would make our life easier, I'm also wary of adding more to legacy
20:19:34 <nitzmahone> ... MS has also learnt their lesson (witness C:\Users and C:\ProgramData)
20:19:47 <dag> the alternative is having parameter "executable" of type path, but then you'd have issues with the arguments too
20:20:03 <dag> nitzmahone: yes :)
20:20:32 <dag> but "C:\Program Files" was a really painful mistake to make...
20:20:55 <nitzmahone> Do you remember "C:\Documents and Settings\..." ? SMH
20:20:59 <jborean93> haha yea
20:21:00 <dag> I'd even argue for not allowing spaces in names, but I wasn't involved in that meeting ;-)
20:21:17 * nitzmahone slaps people when they name files and dirs with spaces
20:21:29 <jborean93> what a great way to reduce the max paths allowed in a users documents
20:21:37 <nitzmahone> My poor dad gets beat up every time he saves a file with me in the room
20:21:49 <jborean93> AAAA IMPORTANT file.doc
20:22:08 <nitzmahone> 😡
20:22:22 <dag> jborean93: what would be your proposal ?
20:23:23 <jborean93> I'm coming round to your side, if we can get cross module_util dependencies so we can reference the `ArgvParser.psm1` in whatever code we are using then it makes sense
20:23:59 <dag> but we'll have to discuss in a core meeting though
20:24:11 <dag> I prefer not to add a type in Windows that would not be accepted for Unix
20:24:29 <jborean93> I don't know the intricacies of Unix argument handling
20:24:36 <dag> I won't bring it up because then we'd get another naming discussion ;-)
20:24:44 <nitzmahone> lol
20:24:51 <dag> jborean93: that's not really relevant, it's similar in type though
20:24:57 <jborean93> I think the main use case in my mind is to be able to set a list of arguments
20:25:15 <dag> jborean93: and a cmdline type would be useful to have, although spaces in names isn't that common
20:25:25 <nitzmahone> (but still would need to be accounted for)
20:25:26 <jborean93> what other uses do you see?
20:26:35 <dag> that's it, you can check for the executable, and have your arguments properly listed
20:27:02 <dag> the parsing of the cmdline string would be different
20:27:13 <dag> but that's a python library for Unix
20:27:21 <nitzmahone> Basically that's implementing shlex.split
20:27:34 <nitzmahone> (of which we have a couple of impls already IIRC)
20:27:39 <jborean93> that might leave out some usages where it could be used in win_package and win_chocolatey where we take in just the arguments
20:27:42 <nitzmahone> only with WIndows quoting rules
20:27:53 <dag> nitzmahone: yes :-)
20:28:33 <nitzmahone> But why would we ever treat the choco/package cases as anything but a naked string, when we're just going to pass it off to the (something we didn't write)?
20:28:37 <dag> I wouldn't mind another type 'arguments' if that makes sense
20:28:47 <jborean93> mainly list conversion to string
20:28:49 <dag> or args
20:29:17 <dag> nitzmahone: same problem, spaces in names
20:29:21 <dag> I guess
20:29:36 <jborean93> or if you want a `"` literal
20:29:47 <dag> in Unix it helps if you can provide a list to execv
20:29:56 <dag> well popen or the newer thing
20:30:24 <nitzmahone> Yeah, Ansible's inconsistent about that internally and IIRC we round-trip it a couple times in different cases. Bleh.
20:30:39 <nitzmahone> (for popen/run_command stuff specifically)
20:34:54 <nitzmahone> Pretty sure I'm not going to have time to do the recursive PS stuff for 2.5, so if that's a prereq this is probably going to have to wait for 2.6 unless Jordan or someone else is feeling ambitious to add support/tests for that to the wrapper and module_validator stuff.
20:35:16 <jborean93> I also want to wait to see the .net utils to see how we could potentially implement that
20:35:33 <jborean93> if one module util is in powershell not sure if the .net stuff can call that
20:35:59 <nitzmahone> Definitely not- I don't want to have a PS dep on the managed stuff, so this would have to be implemented as a pluggable bit.
20:36:39 <jborean93> it sounds like it also is reliant on the unix side adding this type as well
20:36:41 <nitzmahone> I've tried a couple different ways to do that- ultimately, there will likely be a small PS wrapper around the .NET stuff for consumption from powershell
20:37:50 <jborean93> cool, well it sounds like this is a nice to have but reliant on a few things and not likely in 2.5
20:42:44 <jborean93> Well I've got nothing else to add
20:43:06 <nitzmahone> #topic open floor?
20:43:52 <jborean93> Going once?
20:44:19 <jborean93> Going Twice
20:44:49 <jborean93> Going three times
20:44:59 <dag> :-)
20:45:04 <jborean93> sold
20:45:09 <jborean93> #endmeeting