MSH syntax and code sharing

staceyw wrote:

You lost me on the Code sharing bit.  This is a potential issue with any language (script or not).  If you don't post the whole program, you left the reader without a complete example.  Sometimes a snippet will do as your just posting a concept.  Sometimes you may want to post the whole thing.  I see no "fix" that needs to be done in that regard.  You post what makes sense in the context of your post, that is about all you can do.

Have you read my suggestion on fixing it? And have you read my comment on conflicting names without namespaces or such? And the other issue I noted?

Sure, script or not, a program's only complete so long as it's complete. But that's like arguing that we're all going to die eventually, regardless of whether we treat a sickness or not. Or like arguing that a room's gonna get messy sometime or another, so we should just leave it and let it.

It's a matter of severity. With MSH the implementations are customized more than even Linux distributions are. So it'll turn into a mess quicker than any other "language" (platform, to be exact). Linux has a little bit of protection from that nowadays simply due to its long history.

And I've said there should be a way to trace dependencies and "package" them a little bit so that that sort of thing doesn't happen. VS.NET does this to an extent by putting all an app's references in the Bin folder. Shouldn't MSH do something similar?

Don't tell me I only post what makes sense in my own post when you've acknowledged yourself that you haven't even understood it.

staceyw wrote:

First, you edited your post from the first version and you removed the namespace idea and moved things around so I will not address some of that. 

Namespaces is only the latter half of that specific problem, and I guess because things within .msh files are consider local, that's good enough. I still don't know what to think about $profile being public though; all this exceptional behavior makes it less convenient to learn.

The only "moving around" I did was to switch the syntax issue and the sharing issue around because some people have a habit of being prejudgemental, and the moment they disagree or become confused by the more complicated issue, they somehow make assumptions about my ability to write and/or reason properly.

staceyw wrote:

Second, I still don't understand what the issue here is?  How is this different then posting a ksh script?  Either you post the whole thing or you don't.  ksh does not give you some magic copy that follows all the scripts and copies them into the clipboard for you.  I guess you could write such a thing, but why?

Of course ksh doesn't; nor does any other shell language as far as I know. But from the perspective of an app developer, especially a Windows one, that sucks. I don't care if MSH is as good as anything out there else in this regard; I think for the sake of progress, it should be even better.  "No different" means "no better" just as much as it means "no worse".

staceyw wrote:

You seem to want a Project/Solution IDE like VS for MSH.  I would agree that would be nice.  Then you could do things like zip up all the projects and post that.  If you wanted copy/paste every file, you have to do that manually - even with c#, vb, or ksh.

reinux wrote: It's a matter of severity. With MSH the implementations are customized more than even Linux distributions are. So it'll turn into a mess quicker than any other "language" (platform, to be exact). Linux has a little bit of protection from that nowadays simply due to its long history."

What do you mean here? What mess? 

The mess I talk of is one where the more someone uses MSH, the more they and their scripts become reliant on things specific to their installation and configuration. Which I guess is fine, but that'd mean you'd need a way to organize or at least find your way through all of them when you want to share.

I'm not saying I want a project/solution IDE, and I'm pretty sure you knew that, because you made it pretty clear what I want:

staceyw wrote:

ksh does not give you some magic copy that follows all the scripts and copies them into the clipboard for you.  I guess you could write such a thing, but why?

And to answer the question of "why", I don't care if such a thing never existed in the past for shell languages. The fact of the matter is that we're on Windows, and Windows users like things to be as plug & play as possible. That's why.

I'm already going around on blogs finding scripts that are half-dead because half of their code was posted on another day. Do you need a project/solution thing for that? No... but a cmdlet to spit out a function and all of its dependencies would be really nice. Pipe that to a .msh file and voila - out-of-the-box working code.

staceyw wrote:

reinux wrote: Don't tell me I only post what makes sense in my own post when you've acknowledged yourself that you haven't even understood it.

I am trying, but you also have a responsibilty to explain yourself so people can understand what your ideas are.  You may understand 100%, but don't assume everyone can read your mind.

I wrote a damn long post with a rather clear problem, clear example and clear solution, and you complain that you're not a mind reader? Hah. The only reason I wouldn't have been clear to you is if you skimmed what I wrote. And no, I don't think my stuff about namespaces is an excuse either because I did make it clear that those are two separate problems contributing to a single big one.

staceyw wrote:

I still do not understand the code sharing issue.  Can you provide another example of how Code sharing is somehow harder with MSH then with c# or ksh or other?  I think it should be rather easier to share scripts then a c# project for example.

I think you're assuming that I'm antagonizing Microsoft or criticizing MSH just for the sake of argument. Well I'm not. If I were, I would have probably compared it to other things, the way you accuse me of doing. Again, when did I say that sharing code is harder than in C# or ksh? I never said it, and I never implied it. Please don't put words in my mouth.

It's funny, whenever I write a concern or critique something on C9, people immediately get defensive and go nuts to try to shoot me down. If you think my proposals or concerns are dumb, that's fine. I even said very first thing that I'd be glad to hear why I shouldn't be concerned. So please, quit making things personal or assuming I'm here with malicious intent.


So back on topic. C# has no problem; C# isn't meant to be shared in source as much, and when it is, it usually comes with its dependencies and/or sample code. And it's not intended to be quick-and-dirty as MSH is, so C# users are more patient. Unix shells do have the same problem, but Unix users (especially Linux users) are more adept at fixing code with broken dependencies. Also, although ksh and bash users do brag about the benefits of being able to just copy & paste code, it's not part of the design objective, like it is in MSH.

Everyone talking about MSH is talking about how easy it is to just share some cool scripts with each other. I'm sure you've noticed in the videos and such that that's what the devs intend it to be as well. So wouldn't it be disappointing for an MSH user more than to a ksh user when they discover that a script they got doesn't quite run?


In any case, that's the lesser of my two gripes. The syntax thing bugs me too, and I'm interested in hearing what people have to say about that one.

AndyC wrote:

From the perspective of a sysadmin, I don't see the sharing thing as an issue. We are a cautious breed and tend to avoid dependencies unless we can avoid them. For the most part, I don't expect to see scripts with massively complicated dependency chains - after all, we're admins, not developers.

Hmm okay, thanks.

One example is where a Monad developer put up a script find-duplicates on his blog, which relied on attach-md5, which relied on attach-note. All three of these things were posted on different days, and hunting them all down was a pain.

So even though from an app dev background I think it's pretty important, maybe it's not so crucial to MSH's audience. I don't know.

AndyC wrote:

The syntax issue is a curious one though. I haven't played with MSH yet, but this definately seems worrying. I really don't want to have to mess about with differing syntax for what should essentially work the same. Will have to download it and give it a whirl...

Yeah, what really bugs me is the fact that something that looks like it should work fine doesn't work fine, but the code just barges on ahead without warning.

In a really grim example, if someone were controlling a spaceship and they entered something like get-speed 25 50 * feet-to-meters, they'd rightfully assume that that'd convert the speed to meters, but it wouldn't, and the ship would crash. Remember what happened to NASA's probe a few years ago when they forgot to convert imperial to metric...

Obviously no one would be running a spaceship with MSH, but people are going to be using it for manipulating business data. They might never know that there's a bug until it's too late.

staceyw wrote:

Relax a bit reinux.  We are on the same side here.

Right, thanks....... I don't mean to be an -ss but I'm sorta having a hard time knowing what to think.

staceyw wrote:

  Here is what you said:
"I'd get these issues fixed by the first release even if it means breaking CTP code. Otherwise MSH is going to be so bug-prone that it'll be abandoned."

So MSH is bug-prone because you can't find an easy way to share your code on *your blog?  That just seems a bit over the top to me. 

This is why I'm frustrated. You seem to interpret everything I say twice and choose the one that conveniently makes me sound like a furious troll in each instance.

Obviously, obviously I'm not referring to how there's no "easy way to share code on *my blog" alone when I say "bug-prone". Why do you say that?

I said it's bug-prone because 1. people are destined to forget things or use invoke implementations when they share code, and 2. the syntax doesn't just not produce results that a user would expect, it produces results that the user wouldn't expect.

staceyw wrote:

That requirement does not really have anything to do with the language itself, but some external tool you want.

Keep in mind this isn't a bare bones language like C or C#, where the language is only the language constructs plus a few internal data types (int, long etc), and everything else comes from outside.

MSH isn't just a language, it's a shell. It's as much of a Windows application as Office is. The features determine its value as much as the language does. Think practicality.

staceyw wrote:

So basically, you want a tool that given a .msh script will output all that script, and any other script, or c# cmdlet, or function, that that script called?  That could be an interesting script to write in msh itself.  You would need a way to decompile (i.e. reflector style) the cmdlets and hope they are not obfuscated or something.  If this is your need, you may want to post this on scripting ng.  I am sure some scripts will show up. 

Third-party cmdlets are so rarely added to the shell that installing a cmdlet involves reassembling msh.exe with a reference to your new cmdlet using make-shell.exe. Even if it were necessary to share a custom cmdlet, at worst, it'd involve copying the .dll and making a one-line msh "installer".

On the other hand, making a script like this would involve parsing MSH scripts and traversing all the scripts and aliases that it references. Since MSH isn't an ECMA standard language with its BNF available in the documentation like C#, the only people who could do this would be the people on the MSH team itself.

staceyw wrote:

Yup.  The thing you see is actually a thin c# console app that uses the system console like any console app.  This calls into the msh runtime dlls.  You can host these dlls yourself and IIRC that is documented.  They could use a new/updated console.

That's for hosting the MSH engine, and yeah, you can host it in any app. Really cool. Don't think you can analyze scripts directly with it though.

staceyw wrote:

I have not played with it in a while.  But I did a lot of cmdlets in the first two betas.  IIRC, it did not require reassembling msh.exe at all.  Just adding the dll to the right directory and go.  The first version required installer to update a config file, I think it should be xcopy deploy today. At least that was the goal.

That's just for loading DLLs through Assembly, I'm pretty sure. The ones you load by calling [reflection.assembly]::loadfromfile(). Cmdlets still need make-shell.exe to work, at least according to the documentation on winfx.msdn.microsoft.com. I think those are okay since they're self contained, and if they ever do have dependencies they're right there in the bin\debug or bin\release folder if you use an IDE. So long as you can hunt down any references from within MSH.

staceyw wrote:

It would not be easy, but you could do it in c# or msh.  You can even host msh yourself and maybe make certain hooks that would make this easier.  Did you post this question on the scripts ng?  It would be interesting to see some other ideas on this.

That might be easier if it were one of the built-in .NET languages that have CodeDom implementations, but I don't think there'll be any way to analyze MSH scripts without writing at least a lexer. Otherwise if maybe MSH would produce IL, it'd be pretty easy to use the Introspection engine that comes with FxCop...

Yeah, I think I'll try the newsgroups. Most people who've dealt with scripts before are tolerant with semi-borked scripts, but Windows is new to shell scripting, and I think out-of-the-boxness is an absolute must for MSH to be appealing to Windows users in the long term, even for the power users. Especially now that there's going to be better deployment technologies like ClickOnce.