Minimum difference between numbers in a file
You need to make sure you always close resources that can be closed. That means either a try-with-resources block or a try-finally block. You can’t just leave close outside one of these constructs because if an exception gets thrown the close method might not get called.
Arguably, parsing the distances is easier to read using the stream API. You might not yet have learned that part of the language yet, in which case there’s nothing wrong with your loop except that inFile is never closed. Oh, no, it is, but waaaay too late. Keep the scope of the scanner as tight as possible.
Likewise, the code for finding the minimum distance can be written as a stream. Credit to @AnkitSont.
Variable names are really, really important. They should describe the information being pointed to. l is a terrible variable name because it doesn’t tell us anything. list would be a slight improvement, but distances would be much better.
Along the same lines, there’s no reason to cut short variable name lengths. sc instead of scanner doesn’t save you anything, and it makes it harder on the reader because they have to go dig up what an sc is. minDist, diff and minDiffcan and should all be expanded out, and minDist might be better named safeDistance.
Declare variables where they’re first used, and limit their scope as much as possible. This reduces the cognitive load on the reader. minDist can be declared right before your output. It could arguably also be a constant in your class (private static final double declared at the class level). diff can be declared inside the for loop.
Even though the language allows curly braces to be optional for one-line blocks, it is widely regarded best practice that you always include curly braces. To do otherwise is inviting problems later when your code is modified.
Be careful with conditional checks. All of your code will work correctly if there are zero distances in the file until you hit if (l.size() != 1). You really want to check if (l.size() &gt; 1), right?
Your catch block isn’t really doing anything. Uncaught exceptions would effectively be handled the same way - execution would terminate and the stack trace would be logged to System.err.
It's nice to use final when you can to indicate that a variable isn't going to be reassigned. This also reduces the cognitive load of the reader.


If you were to apply all these changes to your code, it might look something like:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Scanner;
import java.util.stream.IntStream;

public final class Main {

    public static void main(final String[] args)
            throws IOException {

        final String filename;
        System.out.print("Please enter the name of the input file: ");
        try (final Scanner scanner = new Scanner(System.in)) {
            filename = scanner.nextLine();
        }

        final double[] distances =
                Files
                    .lines(Paths.get(filename))
                    .mapToDouble((line) -&gt; Double.parseDouble(line.split(",")[1]))
                    .sorted()
                    .toArray();

        final double minimumDifference =
                IntStream
                    .range(1, distances.length)
                    .mapToDouble(i -&gt; distances[i] - distances[i - 1])
                    .min()
                    .getAsDouble();

        final double safeDistance = 5;
        if (minimumDifference &lt; safeDistance) {
            System.out.println("The satellites are not in safe orbits.");
        } else {
            System.out.println("The satellites are in safe orbits.");
        }

        if (distances.length &gt; 1) {
            System.out.println("The minimum distance between orbits (km): " + minimumDifference);
        }
    }

}