Compilation failed in OS X

[davidpelaez]

Hi,

I've been trying for a couple of hours to compile oh without much success:

# github.com/michaelmacinnis/oh
./cell.go:1663: unknown syscall.SysProcAttr field 'Sigdfl' in struct literal
./cell.go:1667: attr.Sys.Foreground undefined (type *syscall.SysProcAttr has no field or method Foreground)
./cell.go:1669: attr.Sys.Joinpgrp undefined (type *syscall.SysProcAttr has no field or method Joinpgrp)

Clearly the missing parts are in the exec_linux.go file but it has a build constraint. Even if I remove it, it wont work. I cannot find a way to make sure this is being included during compilation (it seems like it's not). I just cannot find any place saying how to use patches of the core golang syscall when compiling. :(

Any help is appreciated! Thanks

[davidpelaez]

Hi, I tried this in a linux vm and doesn't compile either! Maybe there's a flag needed so that the syscall patch gets included?

[michaelmacinnis]

Hi David,

Sorry that you wasted a couple of hours. I'm working through changes to support (some form of) job control. Oh currently requires a small patch to Go.

To apply the patch copy exec_linux.go over the existing file in your Go source tree (/usr/share/go/src/pkg/syscall/exec_linux.go on my machine) and run all.bash to re-complile Go. After this you should be able to compile oh. I have only created a patch for Linux at this point but do plan to patch exec_bsd.go and do something that makes sense on systems where these changes are not possible.

Alternatively, with the latest source, you should be able to compile oh by commenting out lines 2824-2835 and 2843-2847 in cell.go:

        t.Lock()

//      if IsInteractive() {
//              attr.Sys = &syscall.SysProcAttr{
//                      Sigdfl: []syscall.Signal{syscall.SIGTTIN, syscall.SIGTTOU},
//              }
//
//              if t.group == 0 {
//                      attr.Sys.Setpgid = true
//                      attr.Sys.Foreground = true
//              } else {
//                      attr.Sys.Joinpgrp = t.group
//              }
//      }

        proc, err := os.StartProcess(arg0, argv, attr)
        if err != nil {
                t.Unlock()
                return nil, err
        }

//      if IsInteractive() {
//              if t.group == 0 {
//                      t.group = proc.Pid
//              }
//      }

        t.pid = proc.Pid

Job control will be broken but everything else should work.

I will add this to the README.

[davidpelaez]

I was lost checking this, sorry for the delay. I managed to compile with the updated comments in the readme. How's the project going? Looks already very far to me from the example sin the readme (most of which I cannot really understand!) I'm curious because I think you make some good arguments about how backwards compatibility has affected the user experience in unix and projects like this are a great exploration into how it could change. If you could share the status from your side in a couple of sentences, that'd be great

[michaelmacinnis]

Thanks for your interest. Oh development is slow but steady.

The job control changes were a bigger detour than I expected but only because I was unlucky enough to reach a point where I needed a feature before it had been added to Go. Go is an incredibly powerful language and previously I had been lucky in that features I needed were either there from the start or were added by others before I needed them. Fortunately, it sounds like it will be possible to make the small changes I require to support job control before Go 1.4.

As you've probably noticed, oh has switched to peterh's, liner, line editing library. There is still work to be done. Rather than registering a Completer, oh should be registering a WordCompleter to allow completion in the middle of a line. The complete and files functions in task.go should also be improved to supply more intelligent completions.

When the go tool subcommand, generate, is released I'm looking forward to removing a lot of duplication and the small makefile that is currently used to build parser.go from parser.y. I'm toying with the idea of invoking the C preprocessor to generate code.

Strings are on their way to becoming objects just like channels and pipes. This means that methods like join, split, sprintf, etc. will move from the 'Text' namespace and become part of a string's context. I'm also working out how to add something like the Bourne shell's trap command to allow catching and handling signals. Other than that the oh language should be fairly stable.

I'd also like to add some tests (other than the scripts in the examples directory) and finish the user's manual at some point.

Improving the Unix shell is difficult. I think you could argue that since the Bourne shell there have only really been 3 successful improved Unix shells: the Korn shell, Bourne-again shell and Z shell. These shells (ksh, bash and zsh) are engineering feats as they add numerous features but can still basically be used as drop in replacements for the Bourne shell. Unfortunately, these shells carry too much weirdness forward and it just seems like some of this weirdness is unnecessary. Most other attempts seem to underestimate the Unix shell and fall into a trap where they must admit that "when executing simple commands the standard Unix command interpreters are preferred" [1] but since executing simple commands is one of the shell's most basic requirements this is the same as admitting that the attempt to improve the shell has failed. It is my hope that there is a fine line somewhere between strict backward compatibility and the more-powerful-but-awkward-for-typical-tasks pitfall and that oh does and can continue to walk this fine line as it solidifies.

[1] Chris S. McDonald. fsh - A Functional UNIX Command Interpreter. Software - Practice & Experience 17(10): 685-700, 1987