The TableParser is broken

[ryanbooker]

It assumes ' ' is always a separator. For ps output, the CMD can be full of spaces.

e.g.

> ps | fsh -p table id

PID       TTY           TIME       CMD       -p       table       id      
38964     ttys000       0:02.21    -zsh     
55462     ttys000       0:00.00    fsh      

Note the -p table id floating up to the right and no longer properly in the CMD field. The lines in the table are broken out as follows:

["PID","TTY","TIME","CMD"]
[["38964" ,"ttys000" ,"0:02.21" ,"-zsh"] ,["55462" ,"ttys000" ,"0:00.00" ,"fsh" ,"-p" ,"table" ,"id"]]

Where it needs to be:

["PID","TTY","TIME","CMD"]
[["38964" ,"ttys000" ,"0:02.21" ,"-zsh"] ,["55462" ,"ttys000" ,"0:00.00" ,"fsh -p table id"]]

It's not clear to me what a good solution to this is. Are there other commands that output tables? Do they all have an "everything else" style last column similar to CMD? i.e. could we assume that the last column should collect up all remaining words (using the column headers count to decide when we're in the last column or something like that)? Should there be a ps specific parser instead?

[ryanbooker]

It's possible this doesn't actually matter and the issue I'm struggling with is something else. The actual issue is that things like the ps example in the help, don't actually work. They don't compile.

ps |fsh -p table 'filter (\(pid:_)-> read pid > 9000)'

[iostreamer-X]

Thanks for pointing this out. Although I gotta admit this used to work, let me look into this today and I will report whatever I find out.

Thanks again!

[iostreamer-X]

So, looking into it I found out that this commit was not tested thoroughly.

The ps example in help filters on the basis of PIDs. And when that filter returns an empty list(lets say you said pid > 30000), the code still tries to do head [] which crashes the program.

The actual issue is that things like the ps example in the help, don't actually work. They don't compile.

Is this the problem you meant when you said this?

[ryanbooker]

Ah that seems to be another issue further down the pipeline. I guess adding another case for (Right []) -> printList [] or something will fix that?

The issue I'm having is this, which seems to be with the function parsing. I'm a relative Haskell novice, so I'm struggling to trace exactly what's happening.

fsh: WontCompile [GhcError {errMsg = "<hint>:1:146: error:\n    lexical error in string/character literal at character '('"}]
CallStack (from HasCallStack):
  error, called at src/TableParser.hs:93:23 in main:TableParser

[ryanbooker]

I just merged in your updates, to confirm. I'm still getting the compile error with the function.

Also, would this be a cleaner implementation of the [] case for res (happy to PR it):

      (Right [])  -> putStrLn header
      (Right res) ->
        do
          outputMatrix <- return $ transpose $ (if length (getWords header) == length (head res) then getWords header else []) : res
          paddedMatrix <- return $ map addTrailingSpaces outputMatrix
          output <- return $ map unwords $ transpose paddedMatrix
          printList output
      (Left err)  -> error $ show err

I also notice a mix of [Char] and String in the types. Some of them become quite hard to read with things like [[[Char]]]. Is there a reason not to use String everywhere?

[ryanbooker]

FYI: Something like this works:
ls -lap |fsh -p table "filter (\((p:_):_) -> p == 'd')"
But this doesn't:
ps |fsh -p table 'filter (\(pid:_)-> read pid > 9000)'

That's why I initially thought it may be related to how the CMD column was being parsed. But the compile error is when running interpret on the functionStr.

[ryanbooker]

PR #7

[iostreamer-X]

I also notice a mix of [Char] and String in the types.

Being a novice myself, I coded without type signatures, then loaded the code in ghci, used :t to get the type and then added what was reported.

Will fix

[ryanbooker]

I changed those in PR #7. :)

I'm looking into the TableParser now to see if I can make some assumptions to get the CMDs in ps and DIRs in ls to be columnised correctly. :)