Code Monkey home page Code Monkey logo

42shelltester's Introduction

weSH

Shell implementation

credits : @abombard, @jgigault, @gkuma, @anouvel

Branch Travis-CI status
master Build Status
develop Build Status

Makefile

custom rules

libs : build the internal libraries (located in ./libs/)

fcleanlibs : apply fclean rule to all internal libs (located in ./libs)

test : run the test suite located in ./test/

submodule : initialize the git submodules and pull the last version of master of all submodules

norme : check the norme of all the .c and .h files (excepted some)

and all rules such as all, clean, fclean and re.

depend rule

The 'depend' rule create all the compilation rules including their dependencies. Run make depend when :

  • adding a source file
  • changing the includes of a source file

The rule use gcc -MM, because of it, the static header should be quoted (#include "libft.h") and not #include <libft.h>.

Git workflow

The is the basic git workflow to work on the weSH repository :

  • setup the repository
$ git checkout master
$ git branch develop && git push -u origin develop

The base of the git workflow is to start working on develop, when the developer want to start a new job, he will create a new feature branch, and when the feature is achieved, he will merge it into develop. When develop accumulate enough features, the team will create a release branch if necessary, and merge release (or develop) into master.

  • create a new feature
$ git checkout develop
$ git pull origin develop
$ git checkout -b feature-<name>
($ git push --set-upstream feature-<name> origin/feature-<name>)
  • merging a feature into develop
$ git checkout develop
$ git pull origin develop
$ git merge feature-<name>
$ git push
$ git branch -d feature-<name>
# if necessary
$ git push origin --delete feature-<name>
  • creating a release
$ git checkout develop
$ git pull origin develop
$ git checkout -b release/<x.y.z> develop
# work on the release
  • incorporate the release into master
$ git checkout master
$ git merge release/<x.y.z>
$ git tag -a <x.y.z> -m <message>
$ git push && git push --tags
$ git checkout develop
$ git merge release/<x.y.z>
$ git push
$ git branch -d release/<x.y.z>
# if necessary
$ git push origin --delete release/<x.y.z>
  • incorporate the develop into master (if no release branch)
$ git checkout master
$ git merge develop
$ git tag -a <x.y.z> -m <message>
$ git push && git push --tags

Logger

The project includes the logger library, and its configured to display all log messages :

logger_init(D_FATAL, "out.log");

To see the output of the logging, run the following command in an other shell :

$ tail -f out.log

42shelltester's People

Contributors

gabkk avatar jgigault avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

42shelltester's Issues

Implement a time-out

And add test that can infinitively loop like:

base64 /dev/urandom | head -c 1000

Fermeture des file descriptors standard et conformance à POSIX

Les tests qui vérifie la fermeture d'un fd standard avec l'opérateur &-, par exemple 21sh > redirections > inputs > 001-close-stdin, sont marqués comme échoué si le fd est remappé sur /dev/null.

Hors la Rationale, et par extension POSIX, ne recommande pas ce comportement.
Cf http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html, section C.2.7 Redirection:

Applications should not use the [n]<&- or [n]>&- operators to execute a utility or application with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing, as this might cause the executed program (or shell built-in) to misbehave. In order not to pass on these file descriptors to an executed utility or application, applications should not just close them but should reopen them on, for example, /dev/null. Some implementations may reopen them automatically, but applications should not rely on this being done.

Un possible fix serait que si le premier call à read retourne 0, alors on suppose que le fd est mappé sur /dev/null.

New test for Globbing

a{,,} est censé donner a a a (le nombre de a etant relatif au nombre d’espace vide entre virgules, cad a{,} -> a a et a{,,,} -> a a a a et ainsi de suite)

$ mv test{,1} -> mv test test1

Implement a prompt to launch test one by one

With something like :

./42ShellTester --prompt

Will run one test, and prompt the user before running the next one, such as :

run test 1... 
<output of test>
V

run next test (yn) > y

run test 2...
<output of test>
... 

It should be usefull to check the logger between each tests.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.