we-sh / logger Goto Github PK

View Code? Open in Web Editor NEW

5.0 5.0 2.0 36 KB

Logger for C programs

License: Apache License 2.0

Makefile 54.83% C 45.17%

logger's Introduction

weSH

Shell implementation

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

Branch	Travis-CI status
master
develop

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

logger's People

Stargazers

Watchers

Forkers

gitburakdeniz quatadah

logger's Issues

Implement a flag to display logger or not

In a multi-part project (consider termcaps, parser, job control, hum). To remove the output of the logger for some part, implement a flag.

general : L_G 0x01
termcaps : L_T 0x02
parser : L_P 0x04
job : L_J 0x08

and call the logger like it :

log_info(L_P | L_T, "%s", "log message");

This will display messages for general (everytime), parser and terncaps, but not job control.

Color display suggestion

Because it is not always clear when there is a lot of debugging messages, we could improve the color display.

Today, we have this situation :

[blue] --------------------- [BLUE] [WHITE] ---------------------------------- [WHITE]
[ 2016/06/16 16:06:53 ] [ INFO    ] (l. 25) parser.c -> parser receives input : "ls"

The fact is that when we have an info log and debug log, sometimes, it is hard to understand that we change of logging type. So 2 possibilities :

[blue] ----------------------------------------- [BLUE] [WHITE] ---------- [WHITE]
[ 2016/06/16 16:06:53 ] [ INFO    ] (l. 25) parser.c -> parser receives input : "ls"

[blue] ---------------------------------------------------------------------- [BLUE]
[ 2016/06/16 16:06:53 ] [ INFO    ] (l. 25) parser.c -> parser receives input : "ls"

Personnaly, I vote for the first, we color from begining to the arrow.

Notice that debug and trace still have the same color (eg default shell color, eg2 white or grey).

The actual :

The new one :

Tell me what you want to do / have :)

How to Add logger.h into main.c File

I am sorry for asking this beginner question, i have only familiarity in adding library from GitHub in python programming. So in C header file, i don't know how to add this file in my program.

I am using visual studio Compiler (MSVC) for compiling the Program.
What should i do to add this library in my program.

Any help will be appreciated

Review the padding of 'file' field

Pad this line :

[ 2016/05/01 14:34:10 ] [ INFO ] (l. 44) lem_parse_input.c -> new line : 2-3

to (spaces are changed by '_' here) :

[ 2016/05/01 14:38:30 ] [ INFO ] (l. 44) lem_parse_input.c___________-> new line : 2-3

with the printf padding flag :

printf("%-30s\n", "hello");

call 1 time (*)printf in display

Because when signal receive, the output is :

[ 2016/05/20 17:03:04 ] [ DEBUG ] (l. 13) job_foreground.c -> [ 2016/05/20 17:03:04 ] [ DEBUG ] (l. 59) signal_sigchld.c -> SIGCHLD received
put job to foreground (pgid: 24294)

instead of

[ 2016/05/20 17:03:04 ] [ DEBUG ] (l. 13) job_foreground.c -> put job to foreground (pgid: 24294)
[ 2016/05/20 17:03:04 ] [ DEBUG ] (l. 59) signal_sigchld.c -> SIGCHLD received

Adding a max_size on the log file

Define somewhere a maximum size for the log file.
Before each new instance of the logger, it will check if the file is not bigger than the size, if yes, delete it.

To not force delete the file, the old file is moved with a timestamp :

out.log > out_<epoch>.log

The user should delete this file if he wants.