Mentoring in Google Code In

I worked on sTeam under FOSSASIA for my Google Summer of Code. Now on passing successfully I will be mentoring in Google Code In and help the younger minds in getting into open source development. I have put up three tasks for GCI. The tasks are an extension on my GSoC project.

The first task involves testing and writing test cases. These are not on any normal testing framework, the framework is developed on pike and specially for the project. Student will have to test the calls to COAL functions. COAL is an in house developed protocol. The task will take around a week to complete. Writing test cases is not a big task but understanding the framework, the protocol and identifying the cases is difficult. The testing framework and test cases already written can be found here.

Second task involves improving the testing framework. The testing framework has been recently developed and still requires some polishing. This task involves identifying and fixing errors in the framework and also extending the framework to add new features. New features can include a better summary of the test cases executed and more details on the errors the occurred if any.

output of testing framework
Output of Testing Framework

Third task involves extending the group command on the steam command line interface, aka, steam-shell. The group command was recently added to the shell and provides only limited functions. Student will be required to understand the use and functionalities of groups from the web interface and code these functionalities for the command line interface. This task will not require more than five days as the interface is easy to understand.

The web interface can be found at http://steam.realss.com/ , students will have to create an account and login to use the interface.

The code for steam-shell can be found at

https://github.com/societyserver/sTeam/blob/gsoc2016-societyserver-devel/tools/steam-shell.pike

Students might face troubles in installing the steam command line interface and tools, therefore we are working on solution to solve this issue. We might provide a debian package that installs the software and then the source code for the tools that need to be worked upon can be downloaded from github and executed.

GSoC 2016 Summary of work done – Improving sTeam

To understand my project you first need to understand what sTeam is. For that you can refer to the blog I wrote http://blog.fossasia.org/what-is-steam/

FOSSASIA_Logo.svggsoc2016-sun-373x373

I started off small by fixing already existing bugs. There were multiple bugs with the edit command in the command line interface of sTeam. I extended the edit command to allow opening of multiple files as tabs in a vim editor. To provide users with more options and to make working on sTeam client easier I added the feature to open new files in steam directly from inside vim. I wrote a vim script to do this and communicated with the sTeam server through this script. My first major task was to implement a TLS connection between the sTeam command line client and the server. For this I had to understand the COAL protocol, which is a home grown protocol for sTeam. I improved the tooling for sTeam by adding in commandso work with groups from the steam-shell and to allow re-login from debug.pike. After this I did some cleaning up work by removing repeated code. The code for login was being repeated in different tools so I made a separate file containing all the common code and imported this in all the tools. I wrote an extensive help command describing every command for steam-shell and giving their syntax. There was some conceptual error in the steam-shell. Rooms and gates are the same but gothrough command was allowing the users to enter a gate but not a room, this was changed to enter command supporting both gates and room, I also changed the output of look command to not show gates and rooms as separate entities.

The next two tasks were entirely new additions to the project. First I wrote a test suite to test the calls to COAL functions. Pike does not have any kind of testing framework so I had to design my own testing framework and write test cases to test the COAL function calls. This will help further development of sTeam as testing of new code becomes easier. The next addition was to write a linux command for sTeam. Steam tools were accessible only from the tools folder that got copied to a particular location on installation. Now on installation users can use the steam command from anywhere to access all the tools.

1. We have combined all the work into two branches.

The commits made by me in each branch can be seen here.

2. I wrote weekly blogs summarizing the work done during the week.

All the blogs can be found at blog.fossasia.org.

The list in reverse chronological order is as follows.

3. A list of tasks covered and all the Pull requests related to each can be seen here

Tasks

Issue

PR

Fix the edit script.

Issue-34

PR-36

Extend edit command for multiple files. Each file opens in its own tab

Issue-38

PR-40

Implementing TLS for COAL to make it COALS.

Issue-47

PR-50

Add the functionality to open files from inside vim

Issue-53

PR-61

Write a plugin to make closing of files easier by closing the logs automatically.

Issue-62

PR-65

Add the command to create groups to steam-shell.

Issue-68 Issue-97

PR-77 PR-98

Add login command to allow relogin in debug.pike

Issue-87

PR-89

Remove repeated code used for login

Issue-91

PR-92

Add a detailed help command to make sTeam easier to use for new users.

Issue-30

PR-95

Change gothrough to enter and allow them to enter rooms as well.

Issue-96

PR-99

Change the output of look command and show rooms and gates under the same section

Issue-100

PR-101

Make steam tools accessible from everywhere

Issue-126 Issue-128 Issue-130Issue-134

PR-127 PR-129 PR-131 PR-135

Write test cases to keep the software error free.

Issue-104 Issue-107 Issue-109Issue-110 Issue-111 Issue-113Issue-116 Issue-118 Issue-122 Issue-124

PR-105 PR-108 PR-112 PR-114 PR-115PR-117 PR-119 PR-123 PR-125

Documentation.

Issue-144

PR-145

4. Scrum Reports

Daily scrum reports have been posted and discussed on #steam-devel on irc.freenode.net and a backup can be found on the mailing list

5. Further Enhancements

  • The testing framework needs to be improved
  • More test cases needs to be added

 

6. Conclusion

In the end I would like to thank Google and FOSSASIA for providing me this wonderful opportunity to learn and collaborate. I would like to thank my mentors Martin and Trilok for guiding me through all the difficult times and helping me solve bugs whenever I got stuck. I would continue contributing to open source and try joining more projects under FOSSASIA to improve my skill set and to get new experience. I will also be taking active part in Google Code In and will love to be a mentor.

sTeam GSoC 2016 Windup

(ˢᵒᶜⁱᵉᵗʸserver) aims to be a platform for developing collaborative applications.
sTeam server project repository: sTeam.
sTeam-REST API repository: sTeam-REST

An overview of the work done by ajinkya007 during Google Summer of code 2016 with FOSSASIA on its project sTeam.

The community bonding period saw the creation of a docker image and a debian package for the sTeam server. The integration of the sTeam shell into vi, improvements in the export and import to git scripts, user and group manipulation commands, sending mails through the commandline, viewing logs and the edit script modifications were done subsequently. The later part of GSOC saw that the sTeam-rest repository was restructured, unit and api-end point tests were performed. The new web interface developed was tested.
The code written during this period by me and siddhant was merged and the conflicts were resolved. The merged code was tested thoroughly as no automated test integration tool supports pike programming language. Documentation was generated using Doxygen and deployed in the gh-pages of the sTeam server repository.

A trello board was maintained throughout the course of GSOC 2016.

Trello Board: sTeam

Accomplishments

Issues Reported and Resolved

A list of tasks covered and all the Pull requests related to each:

Tasks Issue PR
Make changes in the Makefile for installation of sTeam. Issue-25 Issue-27 PR-66 PR-67
Edit script modifications Issue-20 Issue-29 Issue-43 PR-44 PR-48
Indentation of output in steal-shell. Issue-24 PR-42
Integrate steam-shell into vim or emacs. Issue-37 Issue-43 Issue-49 PR-41 PR-48 PR-51
Improve the import and export from git scripts. Issue-9 Issue-14 Issue-16 Issue-18 Issue-19 Issue-46 PR-45 PR-54 PR-55 PR-76
Create, Delete and List the user through commandline Issue-58 Issue-69 Issue-72 PR-59 PR-70 PR-78
Sending Mails through commandline Issue-74 PR-85
Generate error logs and display them in CLI Issue-83 PR-86
Create a file of any mime type from command line. Issue-79 PR-82
Add more commands for group operations. Issue-80 PR-84
Add more utility to the steam-shell Issue-56 Issue-71 Issue-73 PR-57 PR-75 PR-81
Restructure the sTeam-rest repository List of Issue’s List of PR’s
Write test cases to test sTeam-rest api List of Issue’s List of PR’s
Create a debian package and a docker image for easy deployment Create docker image Docker Image
Document the work done Issue 149 sTeam Server Structure, sTeam Server Documentation
Test the web-interface

Commits Merged

During the course of GSOC 2016, work was done on the sTeam and sTeam-rest repositories.

1. The work done on the sTeam repository.

We have combined all the work into two branches for the ease of creating a debian package. The commits made by me in each branch can be seen here.

2. The work done on the sTeam-rest repository

The push request’s sent for the issue’s are yet to be merged in the main repository. The list of PR’s for the sTeam-rest repository.

sTeam-rest PR’s

The weekly blogs

The blogs summarizing the work done during the week were published on my personal website. These can be found on Weekly Blogs
All the blogs can also be found on the Fossasia blog.
The list in reverse chronological order is as follows.

Scrums

Scrum reports were posted on the #steam-devel on irc.freenode.net and sTeam google group. The sTeam trello board also has everyday scrum reports.

Further Improvements

  1. sTeam command line lacks the functionality to read and set the object access permissions. sTeam function analogous to getfacl() to change the sTeam server object permisssions.
  2. sTeam debian package for easy installation of the sTeam server. The debian package is yet to be fully packaged.

Special Thanks

  • I would like to thank my mentors Mario Behling, Hong Phuc Dang, Martin Bahr, Trilok Tourani and my peers for being there to help me and guide me.
  • I would like to thank FOSSASIA, sTeam and Pike Community for giving me this opportunity and guiding me in this endeavour.
  • I would also like to thank Google Summer of Code for this experience.

Feel free to explore the repository. Suggestions for improvements are welcomed.

Checkout the FOSSASIA Idea’s page for more information on projects supported by FOSSASIA.

Writing mime-type handlers in Angular

week15gsoc1

Developing a collaboration platform like sTeam web interface requires careful introspection while rolling out features that involve dealing with media. Any collaboration platform must support as many mime-types as possible, The REST API for sTeam written in pike offers us with the feasibilty of knowing the type of file or mime-type in the response object.
sTeam inbuilt has a mechanism which helps in detecting the mime-type of the file. So the same concept has been extended to the rest api in order to get the mime-type combined in the response object.

The first question that arrives at any user’s mind is what are the mime-types should i support, well basically there are couple of mime-types that can or could be considered in the category of compulsory mime-types that are ought to be supported if you wish to have media content on your application. Let us have a look at the popular or well known mime-types :

  • Text
  • PDF’s
  • Image
  • Audio
  • Video

What if we donot catch the mime-type ?
This is basically a classic question that has the most easiest answer, just ensure that the mime-types which your handler is unable to catch pass them with a flag saying that it is an unknown mime-type. So let us have a look at how it is done :


angular.module('steam')

.controller('workspaceDetailedCtrl', ['$http', '$scope', 'handler', 'localStorageService', 'PDFViewerService', '$sce',
 function ($http, $scope, handler, localStorageService, pdf, $sce) {
  $scope.dataSrc = localStorageService.get('baseurl') + 'home/' + localStorageService.get('currentObjPath')

  $scope.mimeTypeHandler = function () {
    if(localStorageService.get('currentObjMimeType') == 'application/x-unknown-content-type') {
      return 'unknown'
    } else if (localStorageService.get('currentObjMimeType').match(/image\/*/)) {
      return 'image'
    } else if (localStorageService.get('currentObjMimeType') == 'application/pdf') {
      return 'pdf'
    } else if (localStorageService.get('currentObjMimeType').match(/audio\/*/)) {
      return 'audio'
    } else if (localStorageService.get('currentObjMimeType').match(/video\/*/)) {
      return 'video'
    } else if (localStorageService.get('currentObjMimeType').match(/text\/*/) ||
      localStorageService.get('currentObjMimeType') == 'application/x-javascript' ||
      localStorageService.get('currentObjMimeType') == 'application/x-pike') {
      return 'text'
    } else { return 'notfound' }
  }


The best approach for writing a mime-type handler for your application would be :

  • Have a controller that has a function declared for doing the specific operation and pass the mimetype for the object that which you identify, so that the handler can simplify your job in just returning the type of your file
  • Ensure that as many well known mime-types are supported and for the case of new mime-types that depend for specific application just add them to the if...else block
  • Make it a point to catch all the unknown mime-types because when an unknown mime-type is not declared in your handler the browser tends to download the file directly instead of opening the same in your application

NOTE : The service provider localStorageService is very helpful if you have an application that needs to store some data on the user’s/client’s end. So while the user logs into the web interface , localStorageService sets the userpath, objectmimepath and everything else in order to complete the functionality of the application. So gotcha here is that when you have a situation like this localStorageService0 can be useful, since we can both set the data and get the data. Once the user logs out the data is cleared.

Thats it folks,
Happy Hacking !!

 

sTeam Docker Image

(ˢᵒᶜⁱᵉᵗʸserver) aims to be a platform for developing collaborative applications.
sTeam server project repository: sTeam.
sTeam-REST API repository: sTeam-REST

DOCKER IT!

What is Docker?

Docker is open source software to pack, ship and run any application as a lightweight container. Containers are completely hardware and platform independent so you don’t have to worry about whether what you are creating will run everywhere.

In order to facilitate development in all the environments and give the user the ease from the cumbersome installation steps a docker image was made for the sTeam project.
This docker image contains all the necessary dependencies to start the sTeam server.
It also includes the sTeam UI and the Rest API along with it’s dependencies. These have already been installed and developer can start collaborating to it.

docker-image

The docker image can be found at :


https://hub.docker.com/r/ajinkya007/societyserver/

It has all the necessary information for it’s usage and installation.

The dockerfile for the sTeam repository:


FROM ubuntu:latest
RUN apt-get update
RUN apt-get install -y wget git firefox nodejs nodejs-legacy npm
RUN apt-get install -y build-essential mysql-server libmysqld-dev bzip2 libjpeg$
RUN apt-get install -y pike7.8 pike7.8-bzip2 pike7.8-svg
RUN apt-get install -y libxml2-dev libxslt1-dev automake flex
RUN npm install -g npm bower gulp coffee-script jasmine-node frisby
RUN cd home
RUN wget -c https://raw.githubusercontent.com/societyserver/sTeam/steam-package$
RUN git clone www.github.com/societyserver/steam.git
RUN cd sTeam
RUN git checkout societyserver-source
RUN ./build
RUN sudo ./install
RUN cd ..
RUN git clone https://github.com/societyserver/sTeam-web-interface-gsoc-2015.git
RUN cd sTeam-web-interface-gsoc-2015
RUN npm install
RUN cd ..
RUN git clone https://github.com/societyserver/steam-rest.git
RUN cd steam-rest
RUN npm install

Feel free to explore the repository. Suggestions for improvements are welcomed.

Checkout the FOSSASIA Idea’s page for more information on projects supported by FOSSASIA.

Managing multiple states with ui.router

week14gsoc1

Most of the angular applications today have an application router for dealing with the routes of the application. So the web interface for sTeam had the usage of ui.router a library for helping people write routers for complex and big applications. So before i contextualize the usage of ui.router and also give an essence of how routing works with ui.router let us just have a look at the syntax :


angular.module('steam', 'ui.router')

.config(['$locationProvider', '$stateProvider', '$urlRouterProvider', '$provide',
  function ($locationProvider, $stateProvider, $urlRouterProvider, $provide) {

.state('state_name', {
  url: '/route_goes_here',
  templateUrl: '/path_to/templates_go_here.html',
  controller: 'controller_comes_here',
  requireLogin: false || true // depending on the requirement
 })

}])

In the above snippet we can see how to initialize a bare minimum router for an angular application. But to use the ui.router for couple of routes is very much not using the router to the fullest of the features.What are states ?
$state is nothing but a service which is part of the ui.router module. So it can be considered as a service that is responsible for transitioning states accordingly from one state to another. There are many types of states that we can deal with while writing a router for a complex application that deals with multiple and nested states.

  • parent State
  • sibling State
  • grand child state

The parent states generally go with the normal implementation, all we have to use is the state name while declaring the state. But things are not same with sibling state and grandchild state. Let us have a look as to how things are different with them :


// sibling state
.state('^.sibling_name_goes_here', {
  url: '^/route_goes_here',
  templateUrl: '/path_to/templates_go_here.html',
  controller: 'controller_comes_here',
  requireLogin: false || true // depending on the requirement
 })

// grand child state
.state('^.sibling_name_goes_here.grandchild_name_goes_here', {
  url: '^/route_goes_here/:path',
  templateUrl: '/path_to/templates_go_here.html',
  controller: 'controller_comes_here',
  requireLogin: false || true // depending on the requirement
 })

How should multiple routes be handled and how should views be added to the config ?
As explained in my previous article there is a way to use the ui-view in order to write reusable components for the angular application. So let us have a look at how views are to be added to the router’s config :


// state with views
.state('state_name_goes_here', {
  url: '/route_goes_here',
  requireLogin: true || false, // depending on the requirement
  views: {
    'view_name_goes_here': {
      templateUrl: '/path_to/templates_go_here.html',
      controller: 'controller_name_goes_here'
    },
    'view_name_goes_here': {
      templateUrl: '/path_to/templates_go_here.html',
      controller: 'controller_name_goes_here'
    },
    'view_name_goes_here': {
      templateUrl: '/path_to/templates_go_here.html',
      controller: 'controller_name_goes_here'
    }
  }
})

NOTE : We can have the possibility of an application that has a silbing route and all the routes of the parent route are inherited to the sibling route. Enabling this to happen is the beauty of ui.routerNow taking the above syntax we can just add more and more states to the config. It is pretty much that easy to write router config for an application dealing with multiple states. Therefore taking this ahead we can write application router’s for applications that need to handle many routes, but the point here is to understand the point of how the ui.router can be leveraged to the maximum in order to take the best of its features.

Thats it folks,
Happy Hacking !!

sTeam Server Object permissions and Doxygen Documentation

(ˢᵒᶜⁱᵉᵗʸserver) aims to be a platform for developing collaborative applications.
sTeam server project repository: sTeam.
sTeam-REST API repository: sTeam-REST

sTeam Server object permissions

sTeam command line lacks the functionality to read and set the object access permissions. The permission bits are: read,write, execute, move, insert,
annotate, sanction. The permission function was designed analogous to the getfacl() command in linux. It should display permissions as: rwxmias corresponding to the  permission granted on the object.

The the key functions are get_sanction, which returns a list of objects and permissions and sanction_object, which adds a new object and its set of permissions. The permissions is stored as an integer and the function should break the individual bits like getfact().

The permission bits for the sTeam objects are declared in the
access.h

// access.h: The permission bits

#define FAIL           -1 
#define ACCESS_DENIED   0
#define ACCESS_GRANTED  1
#define ACCESS_BLOCKED  2

#define SANCTION_READ          1
#define SANCTION_EXECUTE       2
#define SANCTION_MOVE          4
#define SANCTION_WRITE         8
#define SANCTION_INSERT       16
#define SANCTION_ANNOTATE     32

The get_sanction method defined in the access.pike returns a mapping which has the ACL(Access Control List) of all the objects in the sTeam server.


// Returns the sanction mapping of this object, if the caller is privileged
// the pointer will be returned, otherwise a copy.
final mapping
get_sanction()
{
    if ( _SECURITY->trust(CALLER) )
	return mSanction;
    return copy_value(mSanction);
}

The functions gets the permission values which are set for every object in the server.

The sanction_object method defined in the object.pike sets the permissions for the new objects.


// Set new permission for an object in the acl. Old permission are overwritten.
int sanction_object(object grp, int permission)
{
    ASSERTINFO(_SECURITY->valid_proxy(grp), "Sanction on non-proxy!");
    if ( query_sanction(grp) == permission )
      return permission; // if permissions are already fine

    try_event(EVENT_SANCTION, CALLER, grp, permission);
    set_sanction(grp, permission);

    run_event(EVENT_SANCTION, CALLER, grp, permission);
    return permission;
} 

This method makes use of the set_sanction which sets the permission onthe object. The task ahead is to make use of the above functions and write a sTeam-shell command which would provide the user to easily access and change the permissions for the objects.

Merging into the Source

The work done during GSOC 2016 by Siddhant and Ajinkya on the sTeam server was merged into the gsoc201-societyserver-devel and gsoc2016-source branches in the societyserver repository.
The merged code can be found at:

https://github.com/societyserver/sTeam/tree/gsoc2016-source
https://github.com/societyserver/sTeam/tree/gsoc2016-societyserver-devel

The merged code needs to be tested before the debian package for the sTeam server is prepared. The testing has resulted into resolving of minor bugs.

Doxygen Documentation

The documentation for the sTeam is done using doxygen. The doxygen.pike is written and used to make the documentation for the sTeam server. The Doxyfile which includes the configuration for generating the sTeam documentation is modified and input files are added. The generated documentation is deployed on the gh-pages in the societyserver/sTeam repository.
The documentation can be found at:


http://societyserver.github.io/sTeam/files.html

The header files and the constants defined are also included in the sTeam documentation.

sTeam Documentation:

SocietyserverDoc

sTeam defined constants:

SocietyServerConstants

sTeam Macro Definitions:

SocietyServerMacroDefnitions

Feel free to explore the repository. Suggestions for improvements are welcomed.

Checkout the FOSSASIA Idea’s page for more information on projects supported by FOSSASIA.

Testing, Documentation and Merging

As the GSoC period comes to an end the pressure, excitement and anxiety rises. I am working on the finishing steps of my project. I was successfully able to implement all the task I took up. A list of all the tasks and their implementation can be found here.

https://github.com/societyserver/sTeam/wiki/GSOC-2016-Work-Distribution#roadmap-and-work-distribution-on-steam-for-gsoc-2016

At the start of this week I had about 26 Pull Requests. Each Pull Request had independent pieces of code for a new task from the list. I had to merge all the pull requests and resolve the conflicts. My earlier tasks involved working on the same code so there were a lot of conflicts. I spend hours looking through the code and resolving conflicts. I also had to test each feature after merging any two of the branches. Finally we were able to combine all our code and come up with a branch that contains all the code implemented by me and Ajinkya Wavare.

https://github.com/societyserver/sTeam/tree/gsoc2016-societyserver-devel

https://github.com/societyserver/sTeam/tree/gsoc2016-source

These two are the branches we combined all our code in. I finished my work on linux command for sTeam by adding support for the last two tools which are export and import from git. I worked on to include a help to get new users to understand the use of the command.

https://github.com/societyserver/sTeam/pull/135

I also worked on documentation. I started with the testing suite which is implemented by me. I wrote comments to explain the work and also improved the code by removing unnecessary lines of code. After this I added the documentation for the new command in steam-shell that I had implemented. The command to work with groups from the steam-shell. One of the issue with the testing suite still stands unresolved. I have been breaking my head on it for a week now but to no results. I will attempt to solve it in the coming week.

https://github.com/societyserver/sTeam/issues/109

This error occurs for various objects in the first few runs and then the test suite runs normally error free.

Nested views and templates in Angular

week13gsoc1

sTeam web interface is a perfect example of an Angular application that has multiple views to deal with. The router for sTeam is built using ui.router, which is a classic library for dealing with applications that might have a combination of both parent and child routes that are ought to be reused.

What is the difference between ui-view and ng-view ?
Generally we often get confused with the concept of view when it is used with a router and when it is used inside for injecting templates. The concept of view is simple, it acts like a small placeholder so that we can co-relate or place particular piece of DOM in a required location.
So to understand this better and clear the confusion we must first know how views and templates work. So the web interface for sTeam uses ui.router as a result the concept of ui-view differs from ng-view.
Both of these afore mentioned have different service provides while ui-view belongs to ui.router, ng-view belongs to the default angular’s ngRouter

How do we implement them ?
We must understand that we have three things involved while writing views using ui.router. Let us look at them carefully

  • router
  • template
  • view

Let us suppose the below is an example of the view that contains the configuration in the router


.state('workarea.list', {
  url: '^/room/:path',
  requireLogin: true,
  views: {
    'options': {
      templateUrl: '/views/options.html',
      controller: 'optionsCtrl'
    },
    'workspaceList': {
      templateUrl: '/views/workspaceList.html',
      controller: 'workspaceListCtrl'
    },
    'comments': {
      templateUrl: '/views/comments.html',
      controller: 'commentsCtrl'
    }
  }
})

Let us now have a look at the html


  div class="row"
    div class="col-lg-2"
    div
    div class="col-lg-10"
      legend class="text-left">Comments
      legend
      form class="form-horizontal"
        div class="form-group"
          div class="col-sm-10"
            input class="form-control" type="text" ng-model="commentContent" required id="searchMe"
            span
            span
          div
          div class="col-sm-2"
            button type="button" class="btn btn-primary" ng-click="addComment();">Submit
            button
          div
          div
            ul id="comments"
          
        ul
      div
    div
  form
div
div

Now since we have the html written, we can use the same in the same state that which we have declared in the router we are ready to use the view. Let us observe how should the route be used :


div ui-view="comments" div

So if we carefully observe the ui-view attribute we can see that the name of the view is being written, so accordingly we must declare the name in that place in order to use that view.

Thats it folks,
Happy Hacking !!

Writing linux commands

sTeam includes a number of tools namely steam-shell, debug, edit, import and export from git. These tools are only accessible from the tools folder in the sTeam installation. My task is to make a steam command for linux so that all these tools can be accessible from anywhere just like any other linux application.

Problem: https://github.com/societyserver/sTeam/issues/126

The command structure decided is that we have a global sTeam command and sub commands for each of the tools. This structure can be though of as similar to the structure of the git command. The central git command has many sub commands like branch, checkout, reset, merge, etc. I started with making a pike executable and then changing the installation files to copy this executable to /usr/bin. Now this pike executable becomes accessible from anywhere in the system and acts like a linux command.

https://github.com/societyserver/sTeam/pull/127

I wrote the main function to accept the command line arguments and passed them to a function named resolveParam. In this function I am using an if-else structure to segregate the different sub commands. For shell and debug I started a child process to execute the file for these tools present in /usr/local/lib/steam/tools. The following code snippet gives an example.

void resolveParam(int argc,array(string) argv)
{
if(argv[1]=="shell")
{
array command =({"/usr/local/lib/steam/tools/steam-shell.pike"});
object shell = Process.create_process(command, (["stdin":Stdio.stdin,"stdout":Stdio.stdout,"stderr":Stdio.stderr]));
shell->wait();
}
}

I had some problem when I had to accept more arguments than just the sub command. Foe example the edit command works as ./edit <filename1> <filename2> <filename3>… Using the global command it becomes steam edit <filename1> <filename2> <filename3>… I had to pass all the rest of the arguments to the edit scripts. I had to add them in the command array. The first solution would be to loop through the arguments array and add them all, however pike has a very easy and elegant way of doing it in one sentence.

array command = ({"/usr/local/lib/steam/tools/edit.pike"})+argv[2..];

This gets our global command up and running. Rest of the time I spend on resolving merge conflicts while merging all my previous Pull Requests.

https://github.com/Siddhant085/sTeam/tree/gsoc2016

linux command
output showing the use of steam command