Just a heads-up that Pash\Source\Pash.sln won't open in VS2010 (Pro) "because it has been created with a later version of VS". I've been able to open it with VS2012 Express, though. I'm just opening this issue because I've read somewhere in the docs that VS2010 should be enough to work on the code.

It would be great if the determined 'path' during a set-location could attempt to fix the casing of the actual path to what is on disk(or the drive provider) and not what we type into the console.

For example: (notice how the "Pash" folder is represented as "pash" or "PASH" below?

PASH C:\Code\personal\Pash> cd ../pash
PASH C:\Code\personal\pash> cd ../PASH
PASH C:\Code\personal\PASH>

I would instead expect to see the following

PASH C:\Code\personal\Pash> cd ../pash
PASH C:\Code\personal\Pash> cd ../PASH
PASH C:\Code\personal\Pash>

Bug

PS> 'a' ; 'b'
b
a

Expected

PS> 'a' ; 'b'
a
b

When an enumerable appears in a pipeline, when do we treat it element-by-element, and when do we pass the enumerable as a whole object?

I think are supposed to stream objects 1 at a time, for performance. (Consider when the input is very, very large). I remember reading about this in Payette's book, but it was a long time ago.

In a handful of cases in the PowerShell grammar, whitespace is prohibited between certain terms:

• generic_token_with_subexpr
• member_access
• element_access
• invocation_expression

The only way I know to implement that today is to add whitespace between all terms in the grammar wherever it's allowed. That will add a lot of noise to the grammar, and probably create many shift/reduce conflicts. I have bigger fish to fry, so for now I'm disabling these parts of the grammar.

In addition, I suspect that the command_module grammar is incorrect in the spec., and that the correct productions should prohibit whitespace there, as well. See https://github.com/JayBazuzi/Pash2/issues/8

i'm not so much interested in running full PS elsewhere, but i am interested in doing remoting from non windows clients. Have you, or are you planning on implementing the client side of PSRP (powershell remoting protocol) over some sort of open-wsman?

Currently, Pash say (tested under Fedora 19 x64):

PASH /> cd ~
ERROR: ArgumentException: Illegal characters in path.
ERROR: System.ArgumentNullException: Argument cannot be null.
Parameter name: source
  at System.Linq.Check.Source (System.Object source) [0x00000] in <filename unknown>:0 
  at System.Linq.Enumerable.Any[PSObject] (IEnumerable`1 source) [0x00000] in <filename unknown>:0 
  at System.Management.Pash.Implementation.ExecutionVisitor.VisitCommand (System.Management.Automation.Language.CommandAst commandAst) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 

But ~should be an alias for current user home directory for all supported OS.

1. Build Pash
2. Download & build Irony
3. Run Irony/Irony.GrammarExplorer/Debug/bin/Irony.GrammarExplorer.exe
4. Click ... -> Add grammar
5. Select Pash's System.Automation.Management.dll
6. Open "Grammar Errors" tab

I currently see 4 Shift/Reduce errors.

The official grammar in the PowerShell Language Specification, and the shipping Windows PowerShell v3 parser both allow:

> 1..2..3

If you evaluate it in PowerShell, it will fail (``):

Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Int32".
At line:1 char:1
+ 1..1..1
+ ~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
    + FullyQualifiedErrorId : ConvertToFinalInvalidCastException

If there is a use for this syntax, I don't know what it is.

It's causing the Pash parser to get confused around multiple arguments to a method:

> [char]::IsUpper("abc", 2)       # Produces a false error about expecting `..`

Because chaining array range operators are less important to me than method calls, I'm disabling the former to allow the latter.

We want every source file to have a copyright/license declaration at the top.

We don't want to maintain that by hand.

Write a script to either check for it in Travis.

Monodevelop doesn't seem to be able to interpret the 12.00 MS format solution file, to get around this could create a new solution file called Pash.MonoDevelop.sln?

Projects are almost working the main issues seems to be that MonoDevelop does not like the source files referenced using wildcards, you can see from the screenshot that its taking the "**" literally as a folder name, could maybe reference the files individually? Or else might need to look into some MonoDevelop forums/code.

Commit c77a54d causes xbuild /t:run to use xterm -e to run Pash. That won't work if you don't have xterm.

Hi Jay, in if you are unable to get nunit-consolescript installed on Travis, could we get away with something like:

mono --debug Tools/NUnit-2.6.1/bin/nunit-console.exe Pash.nunit

With mono + linux I had to swap the slashes around and make a path relative in Pash.nunit ( been able to run tests out of MonoDevelop now thanks to your wildcard changes ):

<   <Config name="Debug" binpathtype="Auto" configfile="C:\Users\Jay\GitHub\Pash2\Source\TestHost\bin\Debug\TestHost.exe.config" >
<     <assembly path="Source\TestHost\bin\Debug\TestHost.exe" />
<     <assembly path="Source\PashGui\bin\Debug\PashGui.exe" />
<     <assembly path="Source\ParserTests\bin\Debug\ParserTests.dll" />

---
>   <Config name="Debug" binpathtype="Auto" configfile="Source/TestHost/bin/Debug/TestHost.exe.config" >
>     <assembly path="Source/TestHost/bin/Debug/TestHost.exe" />
>     <assembly path="Source/PashGui/bin/Debug/PashGui.exe" />
>     <assembly path="Source/ParserTests/bin/Debug/ParserTests.dll" />
9,11c9,11
<     <assembly path="Source\TestHost\bin\Release\TestHost.exe" />
<     <assembly path="Source\PashGui\bin\Release\PashGui.exe" />
<     <assembly path="Source\ParserTests\bin\Release\ParserTests.dll" />

---
>     <assembly path="Source/TestHost/bin/Release/TestHost.exe" />
>     <assembly path="Source/PashGui/bin/Release/PashGui.exe" />
>     <assembly path="Source/ParserTests/bin/Release/ParserTests.dll" />

• On Windows, you can go up one directory from root

PASH C:> cd \
PASH C:\> get-location
C:\
PASH C:\> cd ..
PASH C:> get-location
C:

• on Mac

PASH /Users/jasonjarrett/code/personal/Pash> cd /
PASH /> cd users
ERROR: Cannot find path '//users' because it does not exist.
PASH /> 

Currently there are lots and lots of NullReferenceExceptions (for various reasons), e.g. when

• accessing variables that don't exist
• accessing properties that don't exist
• etc.

All of those need to be handled similarly, actually. When null drops to the pipeline it's usually swallowed and not printed in any way (and no exception either). When non-existent properties are accessed they are usually handled as if they have the value null (e.g. for passing through the pipeline or when sorting, etc.).

Now, we could handle that in each place separately, but property look-up for example is very common throughout the codebase (and remembering #112 some instances of that code don't match the behaviour of the others), so implementing and handling such things in one place is probably preferable.

My question would be where that can happen (Some *Helper class? Extension method on System.Type?) and whether that's actually a good idea or whether I'm overlooking something.

I think it would be good to start codifying our conventions around whitespace and would like to propose several steps to accomplish this.

• Create a .editorconfig file with the project's conventions.
• Add to the contributor guidelines a section that recommends contributors install a EditorConfig plugin for their respective editor.

With this in place we could link in comments when the conventions are not quite right, but hopefully this facilitates contributors in such a way that we don't have to remind them much about these conventions.

In a folder with four items, running:

Get-ChildItem | Sort-Object Name 

Outputs the first item's name eight times.

Get-Command | Sort-Object Name # pretty much doesn't ever output anything?

2,4,3 | Sort-Object # throws an exception
"One","Uno" | Sort-Object # throws

It was disabled to allow merging of Jonathan Ben-Joseph's work on LaunchPad. Now we need to work through the warnings and make warnings be errors again.

You should be able to skip the semicolon between statements if the first statement has a script block. For example:

PS> if ($false) { } "hi"         # 2 statements; "hi" is always run

However, the PowerShell grammar as written requires a semicolon after pipeline and flow-control statements:

    statement:
        if_statement
        label_opt   labeled_statement
        function_statement
        flow_control_statement   statement_terminator
        trap_statement
        try_statement
        data_statement
        pipeline   statement_terminator

Which prevents this from working:

PS> { Get-ChildItem }     # should be allowed

As a hack, I am requiring a semicolon between all statements, but not after pipeline and flow-control.

When using xbuild, the Mono C# compiler reports many warnings of unused variables that the Microsoft C# compiler doesn't report. Because we have warnings-as-errors, this results in a build failure. Because we use xbuild on travis, the travis build fails.

Ideally we'd get Mono fixed. Someone should take these issues to them.

In the meantime, I'd like to disable warnings-as-errors (/WX) when building with xbuild. I don't know how to do that.

I'm new to Powershell scripting, but I need it to complete a task on mac..

I was wondering if this library (which is marked pre-alpha) can handle something like this:

$wd = New-Object -ComObject Word.Application
$wd.Visible = $true
$doc = $wd.Documents.Open($filename)
$doc.Tables | ForEach-Object {
  $_.Cell($_.Rows.Count, $_.Columns.Count).Range.Text
}

I've tried using this code on pash, but then it gives me all sorts of errors like

ERROR: $objWord.Visible (generic_token)
ERROR: Exception has been thrown by the target of an invocation.

So to make a long painful story short, is Pash as it stands today capable of executing the above code?

I just want to make node.js spawn a pash process, that parses a word doc containing a table, and return the value back to my node.js process..

It seems that Pash lacks of the main shell feature for now: shell command invocation. I mean that expressions like

PASH C:\> C:\Windows\System32\notepad.exe
PASH C:\> 'C:\Windows\System32\notepad.exe'
PASH C:\> & 'C:\Windows\System32\notepad.exe'

seem not to work: they all're throwing exception

ERROR: Command 'C:\Windows\System32\notepad.exe' not found.

I still haven't found corresponding paragraph in spec about, for example, path resolving and parameter passing rules.

@JayBazuzi, you can lead me to the proper way of implementing this feature? I'll try to do something if I'll have enough spare time.

To improve usability as an interactive shell, Pash should implement tab completion for commands, filenames, keywords, etc.. Consider tab-completion implementations of other shells like Bash, zsh, IPython, and obviously Powershell itself.

How should tests for this work? Completion depends on the environment (list of available filenames, shell commands, etc.), so testing reliably might require a mock environment.

More advanced shells use context-sensitive tab completion, so that pressing Tab will only complete objects of types appropriate for the current cursor position. This would require some way of analyzing partially-typed commands.

I suspect that the command_module grammar is incorrect in the spec. It currently says:

command:
    command_invocation_operator   command_module_opt  command_name_expr   command_elements_opt

command_module:
    primary_expression

command_name_expr:
    command_name
    primary_expression

command_element:
    command_parameter
    command_argument
    redirection

command_argument:
    command_name_expr

There's an ambiguity here, but I suspect the grammar is just written wrong. I believe the correct syntax for a command invocation with a module is:

PS> & MyModule\MyCommand

with no spaces around the \. I can't fix that until the issue with whitespace restriction is resolved (https://github.com/JayBazuzi/Pash2/issues/9)

Problem

The NuGet package for jQuery includes a PowerShell script that contains the following:

trap { ;
continue }

This fails to parse using Pash but is OK with Windows PowerShell. The parser does not like the semi colon without a statement preceding it. So a simpler statement such as the following will fail too.

trap { ; }

The error is:

Syntax error, expected: if, label, switch, foreach, for, while, do, function, filter, break, continue, throw, return, exit, trap, try, data, (, $(, @(, {, @{, decimal_integer_literal, hexadecimal_integer_literal, real_literal, expandable_string_literal, verbatim_string_literal, [, variable, ,, -not, !, -bnot, +, dash, ++, dashdash, -split, -join, generic_token, &, ., }

Attempted Fix

I tried changing the grammar to allow empty statements by switching the term list option to StarList which includes AllowEmpty:

statement_list.Rule =
   MakeListRule(statement_list,
    statement_terminators,
    statement,
    TermListOptions.AllowTrailingDelimiter | TermListOptions.StarList);

This fixes the problem and allows the parser to work but causes 9 more errors in the grammar compared with the existing 3:

Shift-reduce conflict. State S2, lookaheads [; new_line_character]. Selected shift as preferred action. (S2)
Reduce-reduce conflict. State S6, lookaheads: EOF }. Selected reduce on first production in conflict set. (S6)
Shift-reduce conflict. State S7, lookaheads [; new_line_character]. Selected shift as preferred action. (S7)
Reduce-reduce conflict. State S72, lookaheads: ). Selected reduce on first production in conflict set. (S72)
Reduce-reduce conflict. State S74, lookaheads: ). Selected reduce on first production in conflict set. (S74)
Shift-reduce conflict. State S87, lookaheads [[ , + dash ++ dashdash]. Selected shift as preferred action. (S87)
Reduce-reduce conflict. State S144, lookaheads: }. Selected reduce on first production in conflict set. (S144)
Reduce-reduce conflict. State S341, lookaheads: ). Selected reduce on first production in conflict set. (S341)
Shift-reduce conflict. State S349, lookaheads [; new_line_character]. Selected shift as preferred action. (S349)

Grammar change and unit tests are currently in a separate branch.

Attributes on parameter lists look too much like types in member access, and the parser I've written gets confused. For now, I'm disabling attributes.

I'd like to know how we can write tests that only get executed in specific environments (Windows, *nix)?

I haven't seen if we can do this, but possibly an NUnit Category attribute to tag tests and exclude other tests based on the environment?

Any other thoughts on this?

PS > Get-ChildItemsdalfkadsjflakdfjlasdkjfadsf

Process is terminated due to StackOverflowException.

Callstack:

>   Pash.Implementation.CommandManager.CreateCommandProcessor   C#
    System.Management.Automation.Runspaces.Command.CreateCommandProcessor   C#
    Pash.Implementation.LocalPipeline.Invoke    C#
    [External Code] 
    System.Management.Pash.Implementation.ExecutionVisitor.VisitCommand C#
    [External Code] 
    System.Management.Automation.Language.Ast.Visit C#
    System.Management.Pash.Implementation.ExecutionVisitor.VisitPipeline    C#
    [External Code] 
    System.Management.Automation.Language.Ast.Visit C#
    Pash.Implementation.ScriptProcessor.ProcessRecord   C#
    Pash.Implementation.PipelineProcessor.Execute   C#
    Pash.Implementation.LocalPipeline.Invoke    C#
    [External Code] 
    Pash.FullHost.executeHelper C#
    Pash.FullHost.Execute   C#
    Pash.FullHost.Run   C#
    Pash.Program.Main   C#

Consider:

> Write-Host 1,2

Looking at the grammar described in the PowerShell Language Specification, I'm not sure how this should be parsed. I see:

command:
    command-name   command-elementsopt

command-element:
   command-parameter
   command-argument
   redirection

# Why does this even exist?
command-argument:
   command-name-expr

command-name-expr:
   command-name
   primary-expression       # Bug?

I think this is a bug in the grammar, but I would feel reassured if someone could, uh, reassure me.

This should work, but it doesn't:

@{
    a = 'b'
    c = 'd'
}

Consider System.Management.Automation.dll.

Is it important for Pash's assemblies to be named exactly the same way as PowerShell's? If someone has scripts that reference the PowerShell assemblies, we want them to continue working, right? I think this is what Mono does.

Or maybe it's important for the assemblies to have a different name -- on Windows, if an assembly is in the GAC, I think it will get loaded in preference of a local assembly. In that case, we might use Pash.System.Management.Automation.dll. This is what Igor did originally.

I've hear people balk at our projects that produce assemblies named System.*, because there's a general rule that only Microsoft should put things in System.

Don't know if you missed my comment on the Pledgie campaign but I cannot contribute due to an "account restricted" error. Please consider switching to BountySource, Gittip or Flattr.

Consider:

for ( ; ; x ) { }

the x is parsed as the initializer, not as the iterator.

Also,

for ( a ; b ; c ; d ) { } 

the parser allows this, but it should be an error.

Both are the result of a deviation from the official grammar, to avoid shift/reduce errors.

Irony doesn't have an easy way to see the next 2 characters. I wrote an extension to Irony to help, but disabled that code so I could run under a stock Irony.GrammarExplorer.

1. Run Pash under the debugger, with "Break when an exception is thrown" enabled for all .NET exceptions.

2. At the Pash prompt, run a non-GUI (console) program. For example:

   PASH> msbuild

RESULT:

InvalidOperationException thrown & caught in ProcessHasGui()

I like to break on all exceptions when debugging, because it helps me find bugs more easily. That is difficult to do if normal execution patterns throw exceptions.

Is there a way to do this without an exception?

(Maybe this should go in an email list? Experimenting with Issues as a communication system.)

@JamesTryand, @b333z , @staxmanade , @Jaykul, @ForNeVeR,

You are welcome to delete all the branches on your forks except for "master".

Hey,

I took a look at the implementation of functions in Pash. Currently it looks like functions with parameters don't work. Is this a known issue?

Take the following smple example:

function foo($a) { Write-Host $a }; foo(2);
It results in the error:
ERROR: System.NullReferenceException: Object reference not set to an instance of an object

it seems like the parameter doesn't properly get bound in the function's scope. Does anybody know about the current state of the implementation of functions?
And a little related: What about scopes, are they implemented correctly?

Regards,
Stefan

Irony Grammar explorer reports ~20 conflicts in the grammar. It would be nice to drive that to 0, then add it to the Travis tests.

Almost all of the conflicts have to do with newlines, as new_line_opt is peppered through the grammar. That's because newlines in PowerShell are usually statement terminators, but also allowed in certain points within statements. For example:

# Legal code, prints out 'hi'
foreach ($x in ,1)
{
    "Hi!"
}

but:

# broken
,1 | foreach
{
    "Hi!"
}

while:

# Legal code, prints out 'hi'
,1 | foreach {
    "Hi!"
}

In the first case, the grammar for the foreach statement explicitly allows a newline

foreach-statement:
    foreach   new-linesopt   foreach-parameteropt   new-linesopt  (   new-linesopt   variable   new-linesopt   in   new-linesopt   pipeline new-linesopt   )   statement-block

In the second case, the use of foreach is just an alias for a cmdlet, not a special part of the grammar. Essentially, the parser sees the newline and assumes the statement is done; the error comes from the ForEach-Object cmdlet, well after parse time.

So, the newlines are not ever going to appear in the Ast, but they are important markers to help the parser know where it is. So it's OK for them to be ambigious in the grammar, producing shift/reduce conflicts, but Irony still complains about them.

If we have:

Set-Location -Path test

Then we end up with these parameters ( comes out as if Path is type switch and the test is a positional argument ):

1. Name=Path, Value=null
2. Name=null, Value=test

Where we should have ( In this case ):

1. Name=Path, Value=test

After having a think about it I'm thinking whatever breaks up these command_elements up needs to know if a Parameter is type switch, before it can break them up correctly, therefore we would need a CmdLetInfo.IsSwitch(string name)?

Then this bit that currently turns the command_elements into Parameters:

            commandAst.CommandElements
                // the first CommandElements is the command itself. The rest are parameters/arguments
                .Skip(1)
                .Select(ConvertCommandElementToCommandParameter)
                .ForEach(command.Parameters.Add);

Would need to change to work through the list of command_elements consuming and outputting parameters depending on what parameters were Switch parameters?

Does this sounds right?

On my machine they take 8 seconds to run. I want them closer to 1 second.

I'm a comfortable user of PowerShell and a new Mac user.

I would like to see an update to the Readme on how to get setup/build/install this project and some quick -how-to's to start writing and executing powershell (at least on the mac).

I don't mind doing the work to write up the documentation for the Mac and sending a pull request. However I'd love some tips/tricks on how to get started.

• How can I quickly get Mono installed? (brew install mono would be ideal - that's not necessarily this projects responsibility, but some pointers to how-to's would be great)
• How do I get Pash2 installed/build
• How to I start a console where I can start entering powershell?

To reproduce, simply run @(1).Count

Expected result: 1
Actual result:

ERROR: System.InvalidOperationException: Operation is not valid due to the current state of the object
  at System.Linq.Enumerable.Single[MemberInfo] (IEnumerable`1 source, System.Func`2 predicate, Fallback fallback) [0x00000] in :0 
  at System.Linq.Enumerable.Single[MemberInfo] (IEnumerable`1 source) [0x00000] in :0 
  at System.Management.Pash.Implementation.ExecutionVisitor.VisitMemberExpression (System.Management.Automation.Language.MemberExpressionAst memberExpressionAst) [0x00000] in :0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in :0 

As far as I can tell, this happens because @(1) is converted to the scalar 1 by ExecutionVisitor#EvaluateAst. Not sure how to properly fix this though.

We need to be compatible with an assembly that was build with the MS PowerShell. Microsoft's assembly name is Microsoft.PowerShell.Commands.Management.dll

Type name lookup currently considers only the type accelerators and types from four selected assemblies. This is probably not correct, even though the specification is remarkably silent about that.

From my understanding it should probably look through the loaded assemblies in the current AppDomain in search for a type. (Re-reading System.Management/Automation/Language/TypeName.cs, I noticed that's where the hard-coded list comes from, but that list can change, at the very least with Add-Type.)

This would also enable some nice things for testing because we can then just implement and call a method that generates some objects (I'd be reluctant to use Get-Process et al. in tests because their output is hardly deterministic).

When starting Pash I get a lot of crazy control sequences in the terminal for every write operation:

"�[%?%p1%{8}%<%t37%e%p1%{16}%<%t9%p1%{8}%-%d%e38;5;7%;m�[%?%p1%{8}%<%t40%e%p1%{16}%<%t10%p1%{8}%-%d%e48;5;0%;mPash - Copyright (C) Pash Contributors. License: GPL/BSD. See https://github.com/Pash-Project/Pash/"

Is there something wrong with the colour codes? Do I miss an configuration/build parameter?

I tried it with xterm and gnome terminal, same effect.

I moved the project from JayBazuzi/Pash2 -> Pash-Project/Pash. Update your remotes:

 > git remote set-url upstream https://github.com/Pash-Project/Pash.git

@Pash-Project/owners

The official grammar in the PowerShell Language Specification, and the shipping Windows PowerShell v3 parser both allow:

> 1..2..3

If you evaluate it in PowerShell, it will fail (``):

Cannot convert the "System.Object[]" value of type "System.Object[]" to type "System.Int32".
At line:1 char:1
+ 1..1..1
+ ~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [], RuntimeException
    + FullyQualifiedErrorId : ConvertToFinalInvalidCastException

If there is a use for this syntax, I don't know what it is.

It's causing the Pash parser to get confused around multiple arguments to a method:

> [char]::IsUpper("abc", 2)       # Produces a false error about expecting `..`

Because chaining array range operators are less important to me than method calls, I'm disabling the former to allow the latter.

Mono bug https://bugzilla.xamarin.com/show_bug.cgi?id=6541 breaks Irony.

I worked around it in the Irony code. I don't like having changes in our local copy of Irony that we can't push upstream.

At some point, Mono 2.11+ will become widely used, and we should remove this workaround.

Pash can't display a prompt, because the parser fails to parse prompt. It says Invalid character: 'p'.

This of course causes many unit tests to fail.

Need [math] implementation