sTeam API Endpoint Testing

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

sTeam API Endpoint Testing using Frisby

sTeam API endpoint testing is done using Frisby.  Frisby is a REST API testing framework built on node.js and Jasmine that makes testing API endpoints very easy, speedy and joyous.

Issue. Github Issue Github PR
sTeam-REST Frisby Test for login Issue-38 PR-40
sTeam-REST Frisby Tests Issue-41 PR-42

Write Tests

Frisby tests start with frisby.create with a description of the test followed by one of get, post, put, delete, or head, and ending with toss to generate the resulting jasmine spec test. Frisby has many built-in test helpers like expectStatus to easily test HTTP status codes, expectJSON to test expected JSON keys/values, and expectJSONTypes to test JSON value types, among many others.

// Registration Tests
frisby.create('Testing Registration API calls')
.post('', {
email: "[email protected]",
fullname: "Ajinkya Wavare",
group: "realss",
password: "ajinkya",
userid: "aj007"
}, {json: true})
"request-method": "POST",
"request": "register",
"me": restTest.testMe,
"__version": testRegistrationVersion,
"__date": testRegistrationDate
The testMe, testRegistrationVersion and testRegistrationDate are the functions written in the rest_spec.js.

The frisby API endpoint tests have been written for testing the user login, accessing the user home directory, user workarea, user container, user document, user created image,  groups and subgroups.

The REST API url’s used for testing are described below. A payload consists of the user id and password.

Check if the user can login.

Test whether a user workarea exists or not. Here aj workarea has been created by the user.

Test whether a user created container exists or not.

Test whether a user created document exists or not.

Test whether a user created image(object of any mime-type) inside a container exists or not.

Test whether a user created document exists or not. The group name and the subgroups can be queried.
eg. GroupName: groups, Subgroup: test.
The subgroup should be appended using “.” to the groupname.

Here “groups” is a Groupname and “gsoc” is a subgroup of it.



Unit Testing the sTeam REST API

The unit testing of the sTeam REST API is done using the karma and the jasmine test runner. The karma and the jasmine test runner are set up in the project repository.

The karma test runner : The main goal for Karma is to bring a productive testing environment to developers. The environment being one where they don’t have to set up loads of configurations, but rather a place where developers can just write the code and get instant feedback from their tests. Because getting quick feedback is what makes you productive and creative.

The jasmine test runner: Jasmine is a behavior-driven development framework for testing JavaScript code. It does not depend on any other JavaScript frameworks. It does not require a DOM. And it has a clean, obvious syntax so that you can easily write tests.

The karma and jasmine test runner were configured for the project and basic tests were ran. The angular js and angular mocks version in the local development repository was different. This had resulted into a new error been incorporated into the project repo.

Angular Unit-Testing: TypeError ‘angular.element.cleanData is not a function’

When angular and angular-mocks are not of the same version, these error occurs while running the tests. If the versions of the two javascript libraries don’t match your tests will be testing to you.

The jasmine test runner can be accessed from the browser. The karma tests can be performed from the command line. These shall be enhanced further during the course of work.

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 Hero

Our sTeam code base had no tests written and therefore we were facing a lot of issues and were not able to merge our code easily. My next task dealt with this problem. I had to write test cases for the function calls to COAL commands. On some basic research I found out that the only testing framework available for pike is used for testing the pike interpreter itself. This includes a set of scripts. mktestsuite is one of the scripts and is responsible for generating the tests. The problem with this is that the tests should have a particular syntax and since it is used to test interpreter is assumes each line of pike code is a test. This prevented us from writing multiple line tests and also from setting up the client.

Issue: (Establish testing framework), (Add tests for create)

My first approach to the problem was to try using the scripts available to write the tests, however this didn’t turn out very well and tests written were very confusing and out of context. The lines written for setting up the client was also being counted as tests and there was no continuation that is variables defined in one line was not accessible in the next. I realized that this is not going to work out and decided to write my own testing framework. I started by writing a simple testing structure.

The framework has a central script called test.pike. This script is used to run all the test cases. This script uses the the scripts called move.pike and create.pike which are the scripts containing the actual test cases. These scripts contain various functions each of which is a test case and return 1 on passing the case and 0 on failing. test.pike, the central node, is responsible for looping through this functions and calling each of these and recording the result. The framework then outputs the total number of cases passed or failed. Again implementing this became simple as we can import pike scripts as objects and also extract the functions from them.

Running tests for move
Running test for create (Earlier version of framework)

test.pike involved initialization for various variables. It establishes a connection to the server and initializes _Server and me, which are then passed to all the test cases. move.pike has various test cases involving moving things around. Moving user into a room, into a container or to an non existential location and moving a room inside a container. I also got my first failing test case which is moving user into a non existential location. This shouldn’t have been allowed but is not throwing any error and incorrectly writes the trail.

create.pike involved cases creating various kinds of objects and also attempting to create objects for classes that do not exist. As I went along writing these cases I also kept improving the central test.pike. I added the code for creation of a special room for testing while initializing and also clearing this room before destroying the object and exiting.

Solution: (Establish testing framework), (Add tests for create)

Adding extensive help for sTeam

This task was something I came up with as an enhancement because of the problems I faced while using sTeam for the first time. During the first week of my using sTeam I had a tough time getting used to commands and that is when I had opened the issue to improve help. Help for commands were one liners and not very helpful so I took up the task to improve it, so that new users don’t have to face the difficulties that I faced.



Not a lot of technical details were involved in this task but it was time consuming. I write down a few lines explaining what each command does and also added a syntax for the commands. While doing these I also realized more improvements that could be made and added them to my task list. My mentor had explained to me how rooms and gates were the same. I discovered that the command gothrough was violating this as it allowed users to gothrough gates but not rooms. I discussed this on the irc and we came up with a solution that we should change this command to enter and allow it to operate on both rooms and gates.

This enhancement became my next task and I worked on changing this command. The function gothrough was changed to enter and the conditions required for it to work on rooms were added. This paved way for my task. The look command showed rooms and gates under different sections. Now that there were no difference between rooms and gates I combined these two sections to change the output of the look command.

gsoc look
output of look before the changes
gsoc look1
output of look after the changes




By the end of the week I had started on my next task, which was a major one. Writing testing framework and test cases for coal command calls. I will be discussing more about this in my next blog post.

What is sTeam

Whenever I tell someone that I am working for Fossasia under Google Summer of Code, I am asked to explain what my project is all about. Here I give a detailed introduction to sTeam and explain what it actually is.


Well some of you must of heard of MUDs (Multi User Dungeon) sTeam is based on this concept. For those who don’t know what MUDs are I will provide a brief introduction. MUDs are text based games. These games create a kind of real-time virtual world. These games are based on role playing and the user acts like one of the organisms of the virtual world. He can do whatever the organisms could have done in a real world. For example if I represent a man in a virtual world, I can do whatever a man can do, things like walk, talk, eat and stuff. This way the user interacts with his virtual environment.

This whole concept is taken to create a virtual office space. Just like MUDs sTeam creates virtual office space. Now how can we imagine an office? Well it will have rooms each room will have containers with different kinds of files, there will be people moving around working or having meetings. Well all this is possible in sTeam virtually. The user is also carrying a rucksack and can copy objects into this as he moves around. This is what sTeam is.

Steam provides two interfaces web and command line. The web interface can be accessed at and the code is put up at


More of similar projects are available under Fossasia. Check this site for more details

Generating Documentation and Modifying the sTeam-REST API

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


Documentation is an important part of software engineering. Types of documentation include:

  1. Requirements – Statements that identify attributes, capabilities, characteristics, or qualities of a system. This is the foundation for what will be or has been implemented.
  2. Architecture/Design – Overview of software. Includes relations to an environment and construction principles to be used in design of software components.
  3. Technical – Documentation of code, algorithms, interfaces, and APIs.
  4. End user – Manuals for the end-user, system administrators and support staff.
  5. Marketing – How to market the product and analysis of the market demand.


Doxygen is the de facto standard tool for generating documentation from annotated C++ sources, but it also supports other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and UNO/OpenOffice flavors), Fortran, VHDL, Tcl, and to some extent D.
The Doxygen treats files of other languages as C/C++ and creates documentation for it accordingly.
sTeam documentation was tried to be created with the doxygen. But empty documentation was created due to the lack of the doxygen annotations used in the project.
 Doxygen doc generation.
Doxygen Docs
The next way to create documentation was to make use of the autodoc utility provided by the Pike. The utility to generate docs was provided in the later versions of the Pike(>=8.0.155).
The autodoc files are generated and  later these are converted into  html pages. The commands used for generating the autodoc include:-
pike -x extract_autodoc /source
pike -x autodoc_to_html /src /opfile
The autodoc_to_html utility converts a single autodoc file to an html page. As a result a shell script was written to convert all the generated autodoc files to the html file.

shopt -s globstar  
for filename in ./**/*.pike.xml; do  
    if [ -d $(dirname "./"$outputFile) ]; then  
      touch "./"$outputFile  
      mkdir -p $(dirname "./"$outputFile) && touch "./"$outputFile  
    pike -x autodoc_to_html $filename "./"$outputFile  

Autodoc Documentation
AutoDocThe documentation generated by this was less informative and lacked the referrals to other classes and headers. The societyserver project was developed long back but the autodoc utility was introduced in the later versions of pike. As a result the source files lacked the autodoc tags which are required to generate a well informative documentation with bindings to other files.

Restructuring the sTeam-REST API

The sTeam-REST API project made use of the angular-seed to initiate the development during the early phases. However these files still existed in the project. This had lead to a pandemonium and created difficulty in understanding the project. The files had to be removed and the app was in dire need of a restructuring. The following issues have been reported and resolved.

Issue. Github Issue Github PR
sTeam-REST Issues Issues PR

The new UI can be seen below.







Testing the REST API

The functionality to run the tests using the npm test command was added to the project. Now the user can run the tests using these commands instead of the traditional approach of running the tests using jasmine-node and specifying the test directory. The domain name of the urls to which the request was sent was changed. The e2e tests and frisby tests were conducted successfully.

e2e Tests.


Frisby Tests

NPM tests

The next step would be to do add more tests for the REST API.

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.

Re-login in debug.pike

I will first talk about what is debug.pike and then explain my task and then the solution.

Debug.pike gives the user a pike prompt with all the constants from the sTeam client. It is like a self programmable pike client for the sTeam server. All the client side variable are available using which the user can write pike code to interact with the sTeam server. Steam-shell was built on top of this and has functions that perform common actions using these variables.

My task was to build a function to allow re-login as different users. I had worked with the code for connection to the sever and the login part while working on my second task. My second task was to implement TLS and thus I was familiar with the functions available and how COAL was working.

Implementing TLS:

First I tried the code for my function on the prompt of debug.pike itself. My plan of action was to logout the current user and restart the connection. However the logout function gave me a lot of troubles. On logging out I was losing the connection to the server and was not able to establish it back even with the connect_server() function, which establishes a connection between the server and the client. Breaking up the problem I devised a solution for the problem without logging out, that is, calling the login again without logging out.

After calling the function login() when I was unable to get any results I realized that I will have to reset all the variable values that get set during the first login. I moved all the variable initializations to init and called this function after login and the problem was solved. The temporary solution was working fine. I also realized that the logout function was giving me troubles because I was not re-initializing all the variables. So now I was also able to logout and my solution was complete.

My next task was to improve the code. The initialization and the login part of the code was repeated throughout several files with minor changes. I had to bring out the common part put it in a separate file and then inherit. The files I changed were:

  • steam-shell.pike
  • debug.pike
  • edit.pike

I shifted all the uncommon parts to the main of the respective files and then included the common file called client.pike



Now again after this I went back to my previous task and standardized the init function as I had changed it a lot and this would have given a merge conflict later.




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

REST Services

REST is the software architectural style of the World Wide Web. REST (Representational State Transfer) was introduced by Roy Fielding in his doctoral dissertation in 2000. Its purpose is to induce performance, scalability, simplicity, modifiability, visibility, portability, and reliability.It has client/server relationship with a uniform interface and is stateless. REST is most commonly associated with HTTP but it is not strictly related to it.

REST Principles

  • Resources : Each and every component is a resource.A resource is accessed by a common interface using HTTP standard methods.
  • Messages use HTTP methods like GET, POST, PUT, and DELETE.
  • Resource identification through URI: Resources are identified using URI. Resources are represented using JSON or XML.
  • Stateless interactions take place between the server and the client. No context is saved for the requests at the server.The client maintains the state of the session.

HTTP methods

The CRUD(create, retrieve, update and delete ) operations are performed using the HTTP methods.


It is used to retrieve information. GET requests executed any number of times with the same parameters, the results would not change. This makes it idempotent. Partial or conditional requests can be sent. It is a read only type of operation.

Retrieve a list of users:



POST is usually used to create a new entity. It can also be used to update an existing entity. The request will have to do something with the entity provided in the URI.

Create a new user with an ID 2:



PUT request is always idempotent. Executing the same request any number of times will not change the output. PUT can be used to create or update an existing entity.

Modify the user with an ID of 1:



It is idempotent. PATCH requests only updates the specified fields of an entity.

Modify a user with an id of 1:



It can be asynchronous or a long-running request. It removes the resource. It can be removed immediately or at a later instance of time.

Delete a user with an ID of 1:



Installing and activating the REST API

The REST API is developed as an application inside the sTeam server. This simplifies development quite a lot, as we don’t need to restart the server for every change. Instead just the API code gets updated and reloaded. It may eventually be integrated into the core, however the longterm plan is actually to move functionality out of the core, to make development easier.

To get the current version of the API clone the steam-rest repo into your home or to any place where you keep your development repos. Then change to the tools directory of your installation and run import-from-git.

git clone
cd steam-rest
git checkout origin/rest.pike
export steamrest=`pwd`
cd /usr/local/lib/steam/tools
./import-from-git.pike -u root $steamrest /

Note: The new import-from-git.pike script supports importing documents of all mime types.

It is important that the first import is done as root because the API code needs to run with root privileges and it will only do that if the object that holds the source is created as root.

Once the api code is loaded there are just a few tweaks needed to make it work.

We need to fix the mime-type, as the import script is not doing that yet.

OBJ("/sources/rest.pike")->set_attribute("DOC_MIME_TYPE", "source/pike");

Changing the mime type will change the class of the rest api script from Document to DocLpc.

> OBJ("/sources/rest.pike");                                               
(1) Result:,/classes/Document,17,source/pike)
> OBJ("/sources/rest.pike");                                               
(2) Result:,/classes/DocLpc,529,source/pike,0 Instances, ({  }))

This takes a moment, check the type a few times until it’s done. Then instantiate an object from the source, give it a proper name, and move it to the /scripts/ container”

object rest = OBJ("/sources/rest.pike")->provide_instance();
rest->set_attribute("OBJ_NAME", "rest.pike");

Instantiating the object needs to be done as sTeam-root, in order for it to have permissions to run on behalf of other users.

Once this is done you are ready to start using the API.

sTeam-REST API tests

The project contains a set of examples and tests for the RESTful API for the sTeam server.

The code is written in coffee script and needs node.js only for coffeescript translation. Deployment can be done as static javascript files, and does not need any kind of dynamic server for the front-end. The back-end is a RESTful API written for the sTeam server as used by

Development instructions

step 1: install node.js

step 2: clone the repository

git clone

step 3: install node packages:

npm install

This installs all dependencies (including coffee) for our project into the project’s node_modules directory based on the ‘package.json’ file

step 4: start the server

node_modules/.bin/coffee scripts/

but for convenience we can install coffee in the global node environment:

npm install -g coffee-script

so we can just say

coffee scripts/

if the server is working you’ll see:

Listening on port 7000


FrisbyJS is used to test the API. It is run through Jasmine and is based on nodejs.

Once you have nodejs installed, run the following statement to install Frisby and Jasmine:

npm install -g jasmine-node frisby

Then execute the test by:

cd project/directory
jasmine-node test/

The karma testing framework is also used for testing the sTeam REST API.

There were some inherent issues with the test framework which were addressed.

Issue. Github Issue Github PR
Update Update Readme PR-2
Add javascript dependencies Issue-4 PR-6
Add node dependencies Issue-5 PR-7
Add angular-mocks.js script for testing the REST services. Issue-8 PR-9

The project dependencies were not met and this resulted into the error when the project was run on the localhost. The angular-ui-router, angular-bootstrap and bootstrap js frameworks were not installed in the node modules of the project. As a result the bower.json script was modified to include these dependencies.


  "name": "bower",
  "version": "0.1",
  "private": true,
  "ignore": [
  "dependencies": {
    "angular": "",
    "angular-route": "~1.4.8",
    "angular-ui-router": "",
    "angular-bootstrap": "",
    "bootstrap": ""

The node dependencies of karma, frisby and jasmine-node were included in the package.json. These would be installed when the npm install is executed.


"name": "TechGrind",
"version": "0.1.1",
"private": true,
"dependencies": {
"express": "",
"coffee-script": "",
"morgan": "",
"compression": "",
"method-override": "",
"body-parser": "",
"serve-static": "",
"errorhandler": "",
"bower": "",
"jasmine-node": "",
"frisby": "",
"karma": ""
"production_dirs": {
"coffee_src": "src/",
"src": "app/",
"dest": "app_production/"
"devDependencies": {
"scripts": {
"postinstall": "bower 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.

Adding more functions to command line interface of steam-shell

sTeam allows the creation of groups and joining, leaving and listing them. However these functions were only available in the web interface. My task involved the addition of these functions to the command line interface, that is, steam-shell. The task sounded like a difficult one because it involved coding out new commands for the shell and perform actions that have never been done before from the shell. This didn’t turn out to be true.


I began with using and understanding the group functions from the web interface. First I took up the command for the creation of groups. I listed the attributes needed by referring the web interface and then extended the create command already present in the shell to also create groups. The task turned out to be easy against what I thought earlier. This was because of the elegance of pike and modularity of the sTeam server. The code for creation of object was already present in the command and I had to pass the type of object that is group and write a few lines to accept the attributes required.

Next command was for the listing of groups, for this I created a new command called ‘group’ and inside the function called by group I switch cased on the next sub-command to find out if it was join, leave or list. After that I wrote the code to perform the action for each command in their respective cases. This is where the modularity of sTeam helped me a lot. The core portion of these functions turned out to be one liners.

Code to get a list of all groups:

array(object) groups = _Server->get_module(“groups”)->get_groups();

Code to join a group:

int result = group->add_member(me);

Code to leave a group:


group code 1group code 2

Soon all my command were ready. I tested these and everything seemed to be working fine. I pushed my changes and created a new pull request. It was after this that Martin asked me to change the interface. He introduced me to MUDs, Multi User Dungeon. MUDs are type of text based games. The interface for sTeam is based on the these games and these are also an inspiration for the entire project. Just like MUDs create a virtual space we at sTeam create a virtual office space. This helped me to understand not only the interface but also the project. I will be talking more about this in my next blog. Anyways the standard interface is

<action> <object> <additional attributes>

I changed the interface and now the syntax for the commands are

Create a group: create group <group_name>

 [email protected]:~/Documents/sTeam/tools$ ./steam-shell.pike
 Connecting to sTeam server...
 Password for [email protected] [steam]: *****
 Pike v7.8 release 866 running Hilfe v3.5 (Incremental Pike Frontend)
 /home/root> create group group_test
 How would you describe it?^Jtest group
 Subgroup of?^J

List groups: list groups

 [email protected]:~/Documents/sTeam/tools$ ./steam-shell.pike
 Connecting to sTeam server...
 Password for [email protected] [steam]: *****
 Pike v7.8 release 866 running Hilfe v3.5 (Incremental Pike Frontend)
 /home/root> list groups

Here is a list of all groups
abcd Admin coder Everyone Groups group_test
help justnow PrivGroups sTeam testg testg;
testGroup testing test_group WikiGroups


Join a group: join group <group_name>

 [email protected]:~/Documents/sTeam/tools$ ./steam-shell.pike
 Connecting to sTeam server...
 Password for [email protected] [steam]: *****
 Pike v7.8 release 866 running Hilfe v3.5 (Incremental Pike Frontend)
 /home/root> join group group_test
 Joined group group_test

Leave a group: leave group <group_name>

 [email protected]:~/Documents/sTeam/tools$ ./steam-shell.pike
 Connecting to sTeam server...
 Password for [email protected] [steam]: *****
 Pike v7.8 release 866 running Hilfe v3.5 (Incremental Pike Frontend)
 /home/root> leave group group_test


sTeam demo

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


Visual aid can help a person to understand and grasp faster. A demo of the utility added to sTeam so far has been created to help the user base.

The videos have been divided into sections based on the category of the scripts which they execute.

      • Using a docker image.
      • Starting the sTeam server.
      • Running various utilities in the sTeam-shell.
      • Import from git script.
      • Export to git

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.

Extending sTeam shell commands

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

Break the PR

A lot of new commands have been added to the sTeam-shell script.

The earlier PR sent  was addressing a lot of issue’s. As a result the PR was cherry picked and rebased to form smaller PR’s for each issue.

Issue. Github Issue Github PR
Add directory location for Issue-25 PR-66 changes to add the files in the tools directory to the installed location. Issue-27 PR-67

Import from git script

The import to git script was further enhanced to support the feature whereby a user can specify the name of the object in the sTeam directory when a single object is been imported.

The user can now import a single object to the steam work area using the import-from-git script.

The command works for objects of all mime-types.
Two formats for the command are supported.

Issue. Github Issue Github PR
Add utility to support single import in import-from-git script . Issue-16 PR-76

Format 1:

import-from-git.pike ~/gitfolder/zy.mp3 /home/sTeam/

This would create the object in the sTeam directory. The new object would have the same name as the object in the git directory.

Format 2:

import-from-git.pike ~/gitfolder/zy.mp3 /home/steam/ab.mp3

This would create an object with the name ab.mp3 in the sTeam directory. If the object exists from before, the contents of it will be over written with the contents of the object from the git-folder.

Note: Here ‘/’ at the end of the steam directory is used as a distinguishing factor between a directory and an object. Be careful while passing the steam directory in the command or it would throw error.

List User’s

The command to list all the existing user’s in the sTeam server was also added to the steam-shell.

Issue. Github Issue Github PR
List users. Issue-72 PR-78


The user after creation needs to be activated by the root user. Thus a user can then access his steam-shell command line by passing the parameters of user name, host name or port number.

./steam-shell.pike -u uname -h hname -p pno

Passing Arguments to the sTeam-shell

The sTeam shell was modified during it’s integration with vi. This had introduced a bug where by the above parameters where not been able to pass along when a command to the sTeam-shell was passed as an argument. The issue was addressed and resolved.

The user can pass arguments like user name, host and port-number to the steam-shell.pike along with the steam-commands.

Issue. Github Issue Github PR
Add utility to support passing arguments to the sTeam-shell. Issue-71 PR-75


./steam-shell.pike -u user -h host -p portno steam-command


Modularize the tasks

The commands for user manipulation were grouped under their operations like create, delete or list. Thus the commands were modularize.

Issue. Github Issue Github PR
The user commands have been modularized based on the actions they perform. Issue-73 PR-81

The action create, delete and list now support user operations.

To create a user.

create user test

The terminal would ask for password and email-id.

To delete a user

delete user test

To list all the users

list users

Modularize users

Create a file

The command to create a file of any type was added to the sTeam-shell. The code for creation and deletion of objects in the sTeam shell was modified and optimized.

The user can now create a file of any type from the command line.
The mime-type of the file is auto-detected.

Issue. Github Issue Github PR
Create a file from sTeam-shell Issue-79 PR-82


create file filename destination

This would create a file with file name as specified in the given destination. The file name can be like xyz.txt / xyz.pike / xyz.jpg / xyz.mp3. The destination " . " means the current destination.

More commands for groups

The commands to create, join, leave and list groups were added by my colleague Siddhant Gupta. The branch was merged with my working repo. The merge conflicts were successfully resolved. More commands for operations of a group were added.  A user can list all the members of a group, list groups that a user is member of and delete a group.

Issue. Github Issue Github PR
Create a file from sTeam-shell Issue-80 PR-84


  • To list all the groups that a user is member of.
list my groups
  • To view all the members of a group.
list groupname members
  • To delete a group
delete groupname

Support for sending mails

The steam-shell user can now send mails. The utility to support mails was added. The earlier web.spm package was analyzed to find the existing classes used in the web interface in order to support this utility. The browser.pike file can in handy.

Issue. Github Issue Github PR
Add utility to send emails. Issue-74 PR-85
 The user can now send emails from the steam-shell.pike.



This would ask the user to enter the recipients. The recipients can be a sTeam user, a group or an external email.

Note: The recipients should be separated by “,”.

Then the user has to write the email subject and the email body.
After this the user would be then notified about the status of the email.

Successfully sent mail


Mail failed due to wrong recipient


Mail failed due to empty subject


Finally, the command to display the logs of the sTeam server from the steam-shell command line was added.

The user can now see the logs of the sTeam server from the command line. The logs are stored in the /var/log/steam/ directory.

Issue. Github Issue Github PR
Open sTeam-server logs from sTeam-shell. Issue-83 PR-86



The user will be notified about the logs and would be asked to input the name of the logs to open.

The log files include errors, events, fulltext.pike, graphic.pike, http, search.pike, security, server, slow_requests, smtp, spm..pike and tex.pike.
Enter the name of the log files you want to open.
Note: The filenames should be separated by ",".

Input the name of the log files to open. The log files would be then opened in a vi window. User can open multiple logs.

Opened Logs


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