@@ -894,9 +894,10 @@ def add(args)
894894 # operations in order.
895895 #
896896 # Each of the operations appearing in the Array must itself be an Array
897- # with exactly three elements: an operator:: must be :add, :replace, or
898- # :delete an attribute name:: the attribute name (string or symbol) to
899- # modify a value:: either a string or an array of strings.
897+ # with exactly three elements:
898+ # an operator :: must be :add, :replace, or :delete
899+ # an attribute name :: the attribute name (string or symbol) to modify
900+ # a value :: either a string or an array of strings.
900901 #
901902 # The :add operator will, unsurprisingly, add the specified values to the
902903 # specified attribute. If the attribute does not already exist, :add will
@@ -939,13 +940,13 @@ def add(args)
939940 # may not get extended information that will tell you which one failed.
940941 # #modify has no notion of an atomic transaction. If you specify a chain
941942 # of modifications in one call to #modify, and one of them fails, the
942- # preceding ones will usually not be "rolled back, " resulting in a
943+ # preceding ones will usually not be "rolled back", resulting in a
943944 # partial update. This is a limitation of the LDAP protocol, not of
944945 # Net::LDAP.
945946 #
946947 # The lack of transactional atomicity in LDAP means that you're usually
947948 # better off using the convenience methods #add_attribute,
948- # #replace_attribute, and #delete_attribute, which are are wrappers over
949+ # #replace_attribute, and #delete_attribute, which are wrappers over
949950 # #modify. However, certain LDAP servers may provide concurrency
950951 # semantics, in which the several operations contained in a single #modify
951952 # call are not interleaved with other modification-requests received
0 commit comments