]> git.ipfire.org Git - thirdparty/e2fsprogs.git/commitdiff
Fix bogus spaces before '!' and '?' characters in unused programs.
authorTheodore Ts'o <tytso@mit.edu>
Sat, 10 Dec 2005 00:16:40 +0000 (19:16 -0500)
committerTheodore Ts'o <tytso@mit.edu>
Sat, 10 Dec 2005 00:16:40 +0000 (19:16 -0500)
On Mon, Oct 31, 2005 at 01:23:53PM +0000, Martin Michlmayr wrote:
> Package: e2fsprogs
> Version: 1.38-2
> Severity: minor
>
> e2fsprogs isn't consistent in its use of spaces before an exclamation
> mark.  The patch below fixed this by removing some spaces.
> (Interestingly, I couldn't find the error message in the sources where
> I noticed this inconsistency, namely "group descriptors corrupted !").

Patch applied, but none of the source files you touched are actually
compiled in e2fsprogs, and most of them weren't written by me.  :-)

Addresses Debian Bug #336604

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext2ed/dir_com.c
ext2ed/disk.c
ext2ed/doc/ext2ed-design.sgml
ext2ed/doc/ext2fs-overview.sgml
ext2ed/init.c
misc/findsuper.c

index 211a5cf999ae49fe03397c5117b90206e2bd110d..c6b194e0d977cd8e947c5c1c84e0aefd831b9153 100644 (file)
@@ -19,7 +19,7 @@ the functions here are a superset of those in the file_com.c source.
 We assume that the user reached here using the dir command of the inode type and not by using settype dir, so
 that init_dir_info is indeed called to gather the required information.
 
-type_data is not changed ! It still contains the inode of the file - We handle the directory in our own
+type_data is not changed! It still contains the inode of the file - We handle the directory in our own
 variables, so that settype ext2_inode will "go back" to the inode of this directory.
 
 First written on: April 28 1995
index b754bf34fd533d07f270ffa7bccafc0765ebc1ab..d29c7194f59ae53c64c045628ca0831a03eb637f 100644 (file)
@@ -158,7 +158,7 @@ The hex bytes are converted to text, so that they will be readable with a standa
        original=(unsigned char *) malloc (length*sizeof (unsigned char));
 
        if (original==NULL) {
-               wprintw (command_win,"Fatal error - Can\'t allocate %lu bytes !");
+               wprintw (command_win,"Fatal error - Can\'t allocate %lu bytes!");
                refresh_command_win ();fclose (fp);return (0);
        }
        
index 8ac4fcb150cdaef9af7a6c1ba91ebdb641b9e400..3eaca691a18e4d04f4a81d6a9eead6bbc514fb4c 100644 (file)
@@ -109,7 +109,7 @@ technology.
 
 <Para>
 However, I didn't have the luxury of choice when I started my project -
-Linux is a relatively new (and great !) operating system. The extended-2
+Linux is a relatively new (and great!) operating system. The extended-2
 filesystem is even newer - Its first release lies somewhere in 1993 - Only
 passed two years until I started working on my project.
 </Para>
@@ -143,7 +143,7 @@ more than just the principles.
 </Para>
 
 <Para>
-The kernel sources are a rare bonus ! You don't get everyday the full
+The kernel sources are a rare bonus! You don't get everyday the full
 sources of the operating system. There is so much that can be learned from
 them, and it is the ultimate source - The exact answer how the kernel
 works is there, with all the fine details. At the first week I started to
@@ -155,7 +155,7 @@ who starts to build a large puzzle.
 </Para>
 
 <Para>
-However, this was exactly the interesting part ! It is frustrating to know
+However, this was exactly the interesting part! It is frustrating to know
 it all from advance - I think that the discovery itself, bit by bit, is the
 key to a true learning and understanding.
 </Para>
@@ -238,7 +238,7 @@ looking at the sources, of-course).
 <Para>
 I didn't know almost anything of the structure of the ext2 filesystem.
 Reading the sources was not enough - I needed to experiment. However, a tool
-for experiments in the ext2 filesystem was exactly my project ! - Kind of a
+for experiments in the ext2 filesystem was exactly my project! - Kind of a
 paradox.
 </Para>
 
@@ -1106,7 +1106,7 @@ places at the code.
 The various commands are reached by the user through the <Literal remap="tt">dispatch</Literal>
 function. This is not surprising. The fact that can be surprising, at least in
 a first look, is that <Literal remap="tt">you'll find the dispatch call in many of my
-own functions !</Literal>.
+own functions!</Literal>.
 </Para>
 
 <Para>
@@ -2321,7 +2321,7 @@ cd command is a path from <Literal remap="tt">/</Literal>.
 <Para>
 <Literal remap="tt">This is one of the best examples of the power of the object oriented
 design and of the dispatching mechanism. The operation is complicated, yet the
-implementation is surprisingly short !</Literal>
+implementation is surprisingly short!</Literal>
 </Para>
 
 <Para>
@@ -2355,7 +2355,7 @@ void type_ext2___cd (char *command_line)
 </Para>
 
 <Para>
-Note the number of the dispatch calls 
+Note the number of the dispatch calls! 
 </Para>
 
 <Para>
@@ -2366,13 +2366,13 @@ a <Literal remap="tt">dir</Literal> command "enters" the directory, and then we
 specific cd command</Literal> to take us from there (The object is <Literal remap="tt">dir</Literal>, so
 that <Literal remap="tt">dispatch</Literal> will call the <Literal remap="tt">cd</Literal> command of the <Literal remap="tt">dir</Literal> type).
 Note that a symbolic link following could bring us back to the root directory,
-thus the innocent calls above treats nicely such a recursive case !
+thus the innocent calls above treats nicely such a recursive case!
 </Para>
 
 <Para>
 I feel that the above is <Literal remap="tt">intuitive</Literal> - I was expressing myself "in the
 language" of the ext2 filesystem - (Go to the inode, etc), and the code was
-written exactly in this spirit !
+written exactly in this spirit!
 </Para>
 
 <Para>
@@ -3136,7 +3136,7 @@ int action_count (struct struct_file_info *info)
 
 It will just <Literal remap="tt">CONTINUE</Literal> until the last entry. The returned structure
 (of type <Literal remap="tt">struct&lowbar;file&lowbar;info</Literal>) will have its number in the
-<Literal remap="tt">dir&lowbar;entry&lowbar;num</Literal> field, and this is exactly the required number !
+<Literal remap="tt">dir&lowbar;entry&lowbar;num</Literal> field, and this is exactly the required number!
 </Para>
 
 </Sect2>
index 487cc0a71dc49b4d4c0b5f1a780088a7e9997f7d..a6ebf5ab85f01b8a1fd3794de592682b2224608d 100644 (file)
@@ -126,7 +126,7 @@ ext2 filesystem in Linux 1.3, so stay tuned.
 </Sect1>
 
 <Sect1>
-<Title>A filesystem - Why do we need it ?</Title>
+<Title>A filesystem - Why do we need it?</Title>
 
 <Para>
 I thought that before we dive into the various small details, I'll reserve a
@@ -139,7 +139,7 @@ A <Literal remap="tt">filesystem</Literal> consists of two word - <Literal remap
 
 <Para>
 Everyone knows the meaning of the word <Literal remap="tt">file</Literal> - A bunch of data put
-somewhere. where ? This is an important question. I, for example, usually
+somewhere. where? This is an important question. I, for example, usually
 throw almost everything into a single drawer, and have difficulties finding
 something later.
 </Para>
index de504b41930e0378cb33c4149807546ac0ee2ee5..f89d8934b9b398f1415a18adc0d3cd017b507ce0 100644 (file)
@@ -476,7 +476,7 @@ void signal_SIGSEGV_handler (int sig_num)
 
 {
        prepare_to_close ();
-       printf ("Killed by signal %d !\n",sig_num);
+       printf ("Killed by signal %d!\n",sig_num);
        exit (1);
 }
 
index 620f775cc1124b79dd24c877d721c6e7e4873d69..5720f4f7a63c4fbf5370995fffde63d3329c5beb 100644 (file)
@@ -153,7 +153,7 @@ int main(int argc, char *argv[])
                exit(1);
        }
  
-       /* Now, go looking for the superblock ! */
+       /* Now, go looking for the superblock! */
        printf(_("starting at %Ld, with %d byte increments\n"), sk, skiprate);
        printf(_("       thisoff     block fs_blk_sz  blksz grp last_mount\n"));
        for (; lseek64(fd, sk, SEEK_SET) != -1 &&